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Abstract.  We  describe  GINGER,  a  built  system  for  un¬ 
conditional,  general-purpose,  and  nearly  practical  verifi¬ 
cation  of  outsourced  computation.  GINGER  is  based  on 
PEPPER,  which  uses  the  PCP  theorem  and  cryptographic 
techniques  to  implement  an  efficient  argument  system  (a 
kind  of  interactive  protocol).  GINGER  slashes  the  query 
size  and  costs  via  theoretical  refinements  that  are  of  in¬ 
dependent  interest;  broadens  the  computational  model 
to  include  (primitive)  floating-point  fractions,  inequality 
comparisons,  logical  operations,  and  conditional  control 
flow;  and  includes  a  parallel  GPU -based  implementation 
that  dramatically  reduces  latency. 

1  Introduction 

We  are  motivated  by  outsourced  computing :  cloud  com¬ 
puting  (in  which  clients  outsource  computations  to  re¬ 
mote  computers),  peer-to-peer  computing  (in  which 
peers  outsource  storage  and  computation  to  each  other), 
volunteer  computing  (in  which  projects  outsource  com¬ 
putations  to  volunteers’  desktops),  etc. 

Our  goal  is  to  build  a  system  that  lets  a  client  outsource 
computation  verifiably.  The  client  should  be  able  to  send 
a  description  of  a  computation  and  the  input  to  a  server, 
and  receive  back  the  result  together  with  some  auxiliary 
information  that  lets  the  client  verify  that  the  result  is  cor¬ 
rect.  For  this  to  be  sensible,  the  verification  must  be  faster 
than  executing  the  computation  locally. 

Ideally,  we  would  like  such  a  system  to  be  uncondi¬ 
tional,  general-purpose,  and  practical.  That  is,  we  don’t 
want  to  make  assumptions  about  the  server  (trusted  hard¬ 
ware,  independent  failures  of  replicas,  etc.),  we  want  a 
setup  that  works  for  a  broad  range  of  computations,  and 
we  want  the  system  to  be  usable  by  real  people  for  real 
computations  in  the  near  future. 

In  principle,  the  first  two  properties  above  have 
been  achievable  for  almost  thirty  years,  using  powerful 
tools  from  complexity  theory  and  cryptography.  Interac¬ 
tive  proofs  (IPs)  and  probabilistically  checkable  proofs 
(PCPs)  show  how  one  entity  (usually  called  the  veri¬ 
fier)  can  be  convinced  by  another  (usually  called  the 
prove r )  of  a  given  mathematical  assertion — without  the 
verifier  having  to  fully  inspect  a  proof  [5,  6,  19,  32].  In 
our  context,  the  mathematical  assertion  is  that  a  given 
computation  was  carried  out  correctly;  though  the  proof 
is  as  long  as  the  computation,  the  theory  implies — 
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surprisingly — that  the  verifier  need  only  inspect  the 
proof  in  a  small  number  of  randomly-chosen  locations 
or  query  the  prover  a  relatively  small  number  of  times. 

The  rub  has  been  the  third  property:  practicality.  These 
protocols  have  required  expensive  encoding  of  compu¬ 
tations,  monstrously  large  proofs,  high  error  bounds, 
prohibitive  overhead  for  the  prover,  and  intricate  con¬ 
structions  that  make  the  asymptotically  efficient  schemes 
challenging  to  implement  correctly. 

However,  a  line  of  recent  work  indicates  that  ap¬ 
proaches  based  on  IPs  and  PCPs  are  closer  to  practicality 
than  previously  thought  [21,  44,  45,  49].  More  generally, 
there  has  been  a  groundswell  of  work  that  aims  for  poten¬ 
tially  practical  verifiable  outsourced  computation,  using 
theoretical  tools  [11,  12,  20,  24,  25]. 

Nonetheless,  these  works  have  notable  limitations. 
Only  a  handful  [21,  44,  45,  49]  have  produced  work¬ 
ing  implementations,  all  of  which  impose  high  costs  on 
the  verifier  and  prover.  Moreover,  their  model  of  com¬ 
putation  is  arithmetic  circuits  over  finite  fields,  which 
represent  non-integers  awkwardly,  control  flow  ineffi¬ 
ciently,  and  comparisons  and  logical  operations  only  by 
degenerating  to  verbose  Boolean  circuits.  Arithmetic  cir¬ 
cuits  are  well-suited  to  integer  computations  and  numeri¬ 
cal  straight  line  computations  (e.g.,  multiplying  matrices 
and  computing  second  moments),  but  the  intersection  of 
these  two  domains  leaves  few  realistic  applications. 

This  paper  describes  a  built  system,  called  GINGER, 
that  addresses  these  problems,  thereby  taking  general- 
purpose  proof-based  verified  computation  several  steps 
closer  to  practicality.  GINGER  is  an  efficient  argument 
system  [37,  38]:  an  interactive  proof  system  that  assumes 
the  prover  to  be  computationally  bounded.  Its  starting 
point  is  the  PEPPER  protocol  [45]  (which  is  summarized 
in  Section  2).  ginger’s  contributions  are  as  follows. 

(1)  GINGER  demonstrates  the  strength  of  linear  com¬ 
mitment  (§3).  This  paper  proves  that  pepper’s  com¬ 
mitment  primitive  [45],  which  generalizes  the  commit¬ 
ment  primitive  of  Ishai  et  al.  [35],  is  surprisingly  pow¬ 
erful:  it  not  only  commits  an  untrusted  entity  to  a  func¬ 
tion  and  extracts  evaluations  of  that  function  (as  previ¬ 
ously  shown)  but  also  ensures  that  the  function  is  linear. 
(The  primitive  embeds  a  strong  linearity  test.)  This  re¬ 
sult  sharply  reduces  the  required  number  of  queries  (from 
500  to  3)  and  a  key  error  bound,  and  hence  overhead. 

(2)  GINGER  supports  a  general-purpose  programming 
model  (§4).  Although  the  model  does  not  handle  looping 
concisely,  it  includes  primitive  floating-point  quantities. 
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inequality  comparisons,  logical  expressions,  and  condi¬ 
tional  control  flow.  Moreover,  we  have  a  compiler  (de¬ 
rived  from  Fairplay  [39])  that  transforms  computations 
expressed  in  a  general-purpose  language  to  an  executable 
verifier  and  proven  The  core  technical  challenge  is  rep¬ 
resenting  computations  as  additions  and  multiplications 
over  a  finite  field  (as  required  by  the  verification  proto¬ 
col);  for  instance,  “not  equal”  and  “if/else”  do  not  obvi¬ 
ously  map  to  this  formalism,  inequalities  are  problematic 
because  finite  fields  are  not  ordered,  and  fractions  com¬ 
pound  the  difficulties.  GINGER  overcomes  these  chal¬ 
lenges  with  techniques  that,  while  not  deep,  require  care 
and  detail.  These  techniques  should  apply  to  other  proto¬ 
cols  that  use  arithmetic  constraints  or  circuits. 

(3)  GINGER  exploits  parallelism  to  slash  latency  (§5). 
The  prover  can  be  distributed  across  machines,  and  some 
of  its  functions  are  implemented  in  graphics  hardware 
(GPUs).  Moreover,  ginger’s  verifier  can  use  a  GPU 
for  its  cryptographic  operations.  Allowing  the  verifier  to 
have  a  GPU  models  the  present  (many  computers  have 
GPUs)  and  a  plausible  future  in  which  specialized  hard¬ 
ware  for  cryptographic  operations  is  common.2 

We  have  implemented  and  evaluated  GINGER  (§6). 
Compared  to  PEPPER  [45],  its  base,  GINGER  lowers  net¬ 
work  costs  by  1-2  orders  of  magnitude  (to  hundreds 
of  KB  or  less  in  our  experiments).  The  verifier’s  costs 
drop  by  multiples  and  possibly  orders  of  magnitude,  de¬ 
pending  on  the  cost  of  encryption;  if  we  model  encryp¬ 
tion  as  free,  the  verifier  can  gain  from  outsourcing  when 
batch-verifying  as  few  as  20  computations  (down  from 
3900  in  PEPPER).  The  prover’s  CPU  costs  drop  by  10- 
15%,  which  is  not  much,  but  our  parallel  implementa¬ 
tion  reduces  latency  with  near-linear  speedup.  Comput¬ 
ing  with  rational  numbers  in  GINGER  is  roughly  three 
times  more  expensive  than  computing  with  integers,  and 
arithmetic  constraints  permit  far  smaller  representations 
than  a  naive  use  of  Boolean  or  arithmetic  circuits. 

Despite  all  of  the  above,  GINGER  is  not  quite  ready 
for  the  big  leagues.  However,  PEPPER  and  GINGER  have 
made  argument  systems  far  more  practical  (in  some  cases 
improving  costs  by  23  orders  of  magnitude  over  a  naive 
implementation).  We  are  thus  optimistic  about  ultimately 
achieving  true  practicality. 

2  Problem  statement  and  background 

Problem  statement.  A  computer  V,  known  as  the  veri¬ 
fier,  has  a  computation  T  and  some  desired  input  x  that 
it  wants  a  computer  P,  known  as  the  prover,  to  perform. 
P  returns  y,  the  purported  output  of  the  computation,  and 
then  V  and  P  conduct  an  efficient  interaction.  This  in¬ 
teraction  should  be  cheaper  for  V  than  locally  comput- 
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ing  T  (x) .  Furthermore,  if  P  returned  the  correct  answer, 
it  should  be  able  to  convince  V  of  that  fact;  otherwise, 
V  should  be  able  to  reject  the  answer  as  incorrect,  with 
high  probability.  (The  converse  will  not  hold:  rejection 
does  not  imply  that  P  returned  incorrect  output,  only  that 
it  misbehaved  somehow.)  Our  goal  is  that  this  guarantee 
be  unconditional :  it  should  hold  regardless  of  whether 
P  obeys  the  protocol  (given  standard  cryptographic  as¬ 
sumptions  about  P’s  computational  power).  If  P  deviates 
from  the  protocol  at  any  point  (computing  incorrectly, 
proving  incorrectly,  etc.),  we  call  it  malicious. 

2.1  Tools 

In  principle,  we  can  meet  our  goal  using  PCPs.  The  PCP 
theorem  [5,  6]  says  that  if  a  set  of  constraints  is  satisfi- 
able  (see  below),  there  exists  a  probabilistically  check¬ 
able  proof  (a  PCP)  and  a  verification  procedure  that  ac¬ 
cepts  the  proof  after  querying  it  in  only  a  small  number 
of  locations.  On  the  other  hand,  if  the  constraints  cannot 
be  satisfied,  then  the  verification  procedure  rejects  any 
purported  proof,  with  probability  at  least  1  —  e. 

To  apply  the  theorem,  we  represent  the  computation 
as  a  set  of  quadratic  constraints  over  a  finite  field.  A 
quadratic  constraint  is  an  equation  of  degree  2  that  uses 
additions  and  multiplications  (e.g.,  A  ■ Z\  +Z2—Z3  ■ Z 4  = 
0).  A  set  of  constraints  is  satisfiable  if  the  variables  can 
be  set  to  make  all  of  the  equations  hold  simultaneously; 
such  an  assignment  is  called  a  satisfying  assignment.  In 
our  context,  a  set  of  constraints  C  will  have  a  designated 
input  variable  X  and  output  variable  Y  (this  generalizes 
to  multiple  inputs  and  outputs),  and  C(X  =  x,  Y  =  y) 
denotes  C  with  variable  X  bound  to  x  and  Y  bound  to  y. 

We  say  that  a  set  of  constraints  C  is  equivalent  to  a 
desired  computation  T  if:  for  all  x,  y,C(X  =  x,  Y  y)  is 
satisfiable  if  and  only  if  y  =  'T  (x) .  As  a  simple  example, 
increment-by-1  is  equivalent  to  the  constraint  set  {Y  = 
Z  +  1,Z  =  X}.  (For  convenience,  we  will  sometimes 
refer  to  a  given  input  x  and  purported  output  y  implicitly 
in  statements  such  as,  “If  constraints  C  are  satisfiable, 
then  executed  correctly”.)  To  verify  a  computation  y  = 
d/(x),  one  could  in  principle  apply  the  PCP  theorem  to 
the  constraints  C(X  =  x,Y  =  y). 

Unfortunately,  PCPs  are  too  large  to  be  transferred. 
However,  if  we  assume  a  computational  bound  on  the 
prover  P,  then  efficient  arguments  apply  [37,  38]:  V  is¬ 
sues  its  PCP  queries  to  P  (so  V  need  not  receive  the  entire 
PCP).  For  this  to  work,  P  must  commit  to  the  PCP  be¬ 
fore  seeing  V’s  queries,  thereby  simulating  a  fixed  proof 
whose  contents  are  independent  of  the  queries.  V  thus  ex¬ 
tracts  a  cryptographic  commitment  to  the  PCP  (e.g.,  with 
a  collision-resistant  hash  tree  [40])  and  verifies  that  P’s 
query  responses  are  consistent  with  the  commitment. 

This  approach  can  be  taken  a  step  further:  not  even 
P  has  to  materialize  the  entire  PCP.  As  Ishai  et  al.  [35] 
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observe,  in  some  PCP  constructions,  which  they  call  lin¬ 
ear  PCPs ,  the  PCP  itself  is  a  linear  function:  the  verifier 
submits  queries  to  the  function,  and  the  function’s  out¬ 
puts  serve  as  the  PCP  responses.  Ishai  et  al.  thus  design 
a  linear  commitment  primitive  in  which  P  can  commit  to 
a  linear  function  (the  PCP)  and  V  can  submit  function 
inputs  (the  PCP  queries)  to  P,  getting  back  outputs  (the 
PCP  responses)  as  if  P  itself  were  a  fixed  function. 

Pepper  [45]  refines  and  implements  the  outline 
above.  In  the  rest  of  the  section,  we  summarize  the  lin¬ 
ear  PCPs  that  PEPPER  incorporates,  give  an  overview  of 
PEPPER,  and  provide  formal  definitions.  Additional  de¬ 
tails  are  in  Appendix  A.l. 

2.2  Linear  PCPs,  applied  to  verifying  computations 


prover  (P) 
y^'Kx) 


n 


Figure  1 — The  PEPPER  protocol  [45],  which  is  ginger’s  base. 
Though  not  depicted,  many  of  the  protocol  steps  happen  in  par¬ 
allel,  to  facilitate  batching. 


Imagine  that  V  has  a  desired  computation  4>  and  desired 
input  x,  and  somehow  obtains  purported  output  y.  To  use 
PCP  machinery  to  check  whether  y  =  4/(x),  V  compiles 
4/  into  equivalent  constraints  C,  and  then  asks  whether 
C(X  =  x,  Y  =  y)  is  satisfiable,  by  consulting  an  oracle 
tr.  a  fixed  function  (that  depends  on  C,x,y)  that  V  can 
query.  A  correct  oracle  n  is  the  proof  (or  PCP);  V  should 
accept  a  correct  oracle  and  reject  an  incorrect  one. 

A  correct  oracle  n  has  three  properties.  First,  n  is  a 
linear  function,  meaning  that  7r(a)  +  7 t(b)  =  it  (a  +  b)  for 
all  a,  b  in  the  domain  of  n.  A  linear  function  7r :  F"  — >  F 
is  determined  by  a  vector  xv;  i.e.,  n(a)  =  ( a,w )  for  all 
a  £  F".  Here,  F  is  a  finite  field,  and  (a,b)  denotes  the 
inner  (dot)  product  of  two  vectors  a  and  b.  The  parameter 
n  is  the  size  of  w;  in  general,  n  is  quadratic  in  the  number 
of  variables  in  C  [5],  but  we  can  sometimes  tailor  the 
encoding  of  xv  to  make  n  smaller  [45]. 

Second,  one  set  of  the  entries  in  xv  must  be  a  redundant 
encoding  of  the  other  entries.  Third,  xv  encodes  the  actual 
satisfying  assignment  to  C(X  =  x,Y  =  y). 

A  surprising  aspect  of  PCPs  is  that  each  of  these  prop¬ 
erties  can  be  tested  by  making  a  small  number  of  queries 
to  7 r;  if  7r  is  constructed  incorrectly,  the  probability  that 
the  tests  pass  is  upper-bounded  by  e  >  0.  A  key  test  for 
us — we  return  to  it  in  Section  3 — is  the  linearity  test  [16]: 
V  randomly  selects  q\  and  qi  from  F"  and  checks  if 
7T (qi)  +  77(^2)  =  tt(<7i  +  qf).  The  other  two  PCP  tests 
are  the  quadratic  correction  test  and  the  circuit  test. 

The  completeness  and  soundness  properties  of  linear 
PCPs  are  defined  in  Section  2.4.  A  detailed  explanation 
of  why  the  mechanics  above  satisfy  those  properties  is 
outside  our  scope  but  can  be  found  in  [5,  13,  35,  45], 

2.3  Our  base:  PEPPER 


Specify  and  compute.  V  transforms  its  desired  compu¬ 
tation,  'I',  into  a  set  of  equivalent  constraints,  C.  V  sends 
4/  (or  C )  to  P,  or  P  may  come  with  them  installed. 

To  gain  from  outsourcing,  V  must  amortize  the  costs  of 
compiling  4>  to  C  and  generating  queries.  Thus,  V  verifies 
computations  in  batches  [45]  (although  they  need  not  be 
executed  in  a  batch).  A  batch  (of  size  /?)  refers  to  a  set  of 
computations  in  which  4/  is  the  same  but  the  inputs  are 
different;  a  member  of  the  batch  is  called  an  instance. 
In  the  protocol,  V  has  inputs  x\,...,xp  that  it  sends  to 
P  (not  necessarily  all  at  once),  which  returns  y  1 , . . .  ,yp; 
for  each  instance  ;,  y,  is  supposed  to  equal  4/(x,). 

For  each  instance  i,  an  honest  P  stores  a  proof  vector 
w i  that  encodes  a  satisfying  assignment  to  C(X  =  x,-,  Y  = 
y,);  w i  is  constructed  as  described  in  Section  2.2.  Being  a 
vector,  xv i  can  also  be  regarded  as  a  linear  function  7 r,- — or 
an  oracle  of  the  kind  described  above. 

Extract  commitment.  V  cannot  inspect  {tt,}  directly 
(they  are  functions;  written  out,  they  would  have  an  en¬ 
try  for  each  value  in  a  huge  domain).  Instead,  V  extracts  a 
commitment  to  each  7r,-.  To  do  so,  V  randomly  generates  a 
commitment  vector  r  £  F".  V  then  homomorphically  en¬ 
crypts  each  entry  of  r  under  a  public  key  pk  to  get  a  vector 
Enc (pk,r)  =  (Enc(pk,  n),  Er\c(pk,  r2), . . . ,  Er\c(pk,  r„)). 
We  emphasize  that  Enc(-)  need  not  be  fully  homomor¬ 
phic  encryption  [27]  (which  remains  unfeasibly  expen¬ 
sive);  PEPPER  uses  ElGamal  [23,  45], 

V  sends  (Enc(pk,  r),pk)  to  P.  If  P  is  honest,  then  7 r,-  is 
linear,  so  P  can  use  the  homomorphism  of  Enc(-)  to  com¬ 
pute  Enc(pk,  7r,(r))  from  Enc (pk.r),  without  learning 
r.  P  replies  with  (Er\c(pk,  7Ti(r)), . . . ,  Er\c(pk,  np(r))), 
which  is  P’s  commitment  to  {7 r,}.  V  then  decrypts  to  get 
(tt!  (r),  ■  ■  ■ ,  ttpir)). 


We  now  walk  through  the  three  phases  of  Pepper  [45], 
which  is  depicted  in  Figure  1.  The  approach  is  to  com¬ 
pose  a  linear  PCP  and  a  linear  commitment  primitive  that 
forces  the  prover  to  act  like  an  oracle. 


Verify.  V  now  generates  PCP  queries  £  F", 

as  described  in  Section  2.2.  V  sends  these  queries  to  P, 
along  with  a  consistency  query  t  =  r+y~]jj.i  ay<7;,  where 
each  ctj  is  randomly  chosen  from  F  (here,  •  represents 
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scalar  multiplication). 

For  ease  of  exposition,  we  focus  on  a  single  proof  7r,; 
however,  the  following  steps  happen  fJ>  times  in  parallel, 
using  the  same  queries  for  each  of  the  /?  instances.  If  P 
is  honest,  it  returns  (7t,(^i), . . . ,  7 r,/^),  7r, ■(/)).  V  checks 
that  7 Tj(t)  =  TTj(r)  +  J2j=i  ai  '  ni((lj );  this  is  known  as 
the  consistency  test.  If  P  is  honest,  then  this  test  passes, 
by  the  linearity  of  n.  Conversely,  if  this  test  passes  then, 
regardless  of  P's  honesty,  V  can  treat  P’s  responses  as  the 
output  of  an  oracle  (this  is  shown  in  previous  work  [35, 
45]).  Thus,  V  can  use  {77,- (<71 ), . . . ,  7r,(<y;j)}  in  the  PCP 
tests  described  in  Section  2.2. 

2.4  PCPs  and  arguments  defined  more  formally 

The  definitions  of  PCPs  [5,  6]  and  argument  systems  [19, 
32]  below  are  borrowed  from  [35,  45]. 

A  PCP  protocol  with  soundness  error  e  includes  a 
probabilistic  polynomial  time  verifier  V  that  has  access  to 
a  constraint  set  C.  V  makes  a  constant  number  of  queries 
to  an  oracle  7 r.  This  process  has  the  following  properties: 

•  PCP  Completeness.  If  C  is  satisfiable,  then  there  ex¬ 
ists  a  linear  function  7 r  such  that,  after  V  queries  7r, 
Pr{  V  accepts  C  as  satisfiable}  =  1,  where  the  proba¬ 
bility  is  over  V's  random  choices. 

•  PCP  Soundness.  If  C  is  not  satisfiable,  then 
Pr{  V  accepts  C  as  satisfiable}  <  e  for  all  purported 
proof  functions  7t. 

An  argument  |7\  V)  with  soundness  error  e  comprises  P 
and  V,  two  probabilistic  polynomial  time  (PPT)  entities 
that  take  a  set  of  constraints  C  as  input  and  provide: 

•  Argument  Completeness.  If  C  is  satisfiable  and  P  has 
access  to  a  satisfying  assignment  z,  then  the  interac¬ 
tion  of  V(C)  and  P(C,z )  makes  V(C)  accept  C’s  satis¬ 
fiability,  regardless  of  P’s  random  choices. 

•  Argument  Soundness.  If  C  is  not  satisfiable,  then  for 
every  malicious  PPT  P* ,  the  probability  over  V’s  ran¬ 
dom  choices  that  the  interaction  of  V(C)  and  P*(C) 
makes  V(C)  accept  C  as  satisfiable  is  less  than  e. 

3  Protocol  refinements  in  GINGER 

In  principle,  PEPPER  solves  the  problem  of  verified  com¬ 
putation.  The  reality  is  less  attractive:  pepper’s  com¬ 
putational  burden  is  high,  its  network  costs  are  absurd, 
and  its  applicability  is  limited  (to  straight  line  numeri¬ 
cal  computations).  Our  system,  GINGER,  mitigates  these 
issues:  it  lowers  costs  through  protocol  refinements  (pre¬ 
sented  in  this  section),  and  it  applies  to  a  much  wider 
class  of  computations  (as  we  discuss  in  Section  4). 

ginger’s  refinements  eliminate  many  queries,  by  re¬ 
lying  on  a  new  analysis  of  the  base  commitment  primi¬ 
tive.  To  motivate  this  analysis,  we  note  that  there  is  some¬ 


thing  seemingly  redundant  in  the  base  machinery  (see 
Figure  1):  why  does  the  linear  PCP  require  a  linearity 
test  (§2.2)  if  an  honest  prover  depends  on  the  linear¬ 
ity  of  its  function  tv  to  pass  the  linear  commitment  pro¬ 
tocol’s  consistency  test  (§2.3)?  Can  we  remove  one  of 
these  tests,  or  combine  them  somehow?  The  reason  that 
PEPPER  appears  to  need  both  tests  is  that  their  guarantees 
are  (so  far)  subtly  different: 

•  Consistency  test  (§2.3):  First,  an  honest  prover  is 
guaranteed  to  pass  this  test.  Second,  if  the  prover — 
even  a  cheating  one — passes  this  test,  then  it  is  very 
likely  bound  to  some  function  (as  shown  in  [35,  45]). 

•  Linearity  test  (§2.2):  This  test  is  needed  in  case  the 
prover  cheats — it  establishes  that  7r  is  linear  (as  re¬ 
quired  by  the  rest  of  the  PCP  protocol).  More  accu¬ 
rately,  if  7T  is  far  from  being  linear,  the  test  is  some¬ 
what  likely  to  catch  that  case. 

Yet,  it  seems  unsatisfying  that  both  tests  are  required 
when  composing  linear  commitment  and  the  linear  PCP: 
can  a  prover  really  pass  the  consistency  test  systemati¬ 
cally  with  a  function  that  the  linearity  test  would  reject? 
In  fact,  our  intuitive  dissatisfaction  is  well-founded:  this 
paper  proves  that  the  commitment  primitive  (which  in¬ 
cludes  the  consistency  test)  is  far  stronger  than  the  linear¬ 
ity  test.  Put  simply,  even  a  cheating  prover  is  very  likely 
bound  to  a  function  that  is  linear,  or  almost  so. 

Practically,  this  result  saves  query  generation  and  re¬ 
sponse  costs.  For  one  thing,  we  can  eliminate  linearity 
tests  from  the  protocol.  More  significantly,  we  eliminate 
amplification:  PEPPER  needed  to  repeat  the  protocol  to 
turn  the  linearity  test’s  guarantee  of  “somewhat  likely” 
into  “very  likely”.  In  contrast,  our  result  already  gives  a 
guarantee  of  “very  likely”,  so  no  repetition  is  required. 

More  broadly,  this  result  means  that  the  commit¬ 
ment  primitive  is  considerably  more  powerful  than 
was  realized — it  efficiently  commits  an  untrusted  en¬ 
tity  to  a  linear  function  and  extracts  evaluations  of  that 
function — and  may  apply  elsewhere. 

Details.  The  protocol  refinements  are  rooted  in  a 
strengthened  soundness  analysis.  Soundness  error  (for 
example,  e  in  Section  2.4)  refers  to  the  probability  that 
a  protocol  or  test  succeeds  when  the  condition  that  it  is 
verifying  or  testing  is  actually  false.  The  ideal  is  to  have 
a  small  upper-bound  on  soundness  error. 

The  soundness  of  the  PCP  protocol  in  Section  2.2  and 
Appendix  A.  1  is  connected  to  the  soundness  of  linearity 
testing  [16].  Specifically,  the  base  analysis  proves  that  if 
the  prover  returns  y  ^  Tfx),  then  the  prover  survives  all 
tests  (linearity,  quadratic  correction,  circuit)  with  prob¬ 
ability  less  than  7/9  (requiring  p  runs  to  make  (7/9)p 
small).  The  7/9  derives  from  a  result  [8]  that  if  the  proof 
oracle  is  not  “somewhat  close”  to  linear,  then  the  linear- 
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PEPPER  [45] 

GINGER 

PCP  encoding  size  (n) 

s2  +  s,  in  general 

s2  +  s,  in  general 

T’s  per-instance  CPU  costs 

Issue  commit  queries 

Process  commit  responses 
Issue  PCP  queries 

Process  PCP  responses 

(e  +  2c)  ■  n//3 
d 

P-(X'f+e'-f+5c)-n//3 
p  ■  (2f'  +  |*|  +  |y|)  •/ 

( e  +  2c)  ■  ft/ / 3 
d 

( X-f  +  t-f  +  2c)-n/p 
(2£+\x\  +  |y|)  •/ 

P’s  per-instance  CPU  costs 

Issue  commit  responses 

Issue  PCP  responses 

h  ■  ft 

(p-f  +  1)  •/•  ft 

h  ■  ft 

(<+!)•/•« 

Network  cost  (per  instance) 

((p-e'+iy\p\+mn/P 

((l+l)-\p\  +  \t\)-n/P 

PCP  soundness  error 

Overall  soundness  error 

(7/9)p  =  2.3  •  1(T8 

2.4  ■  10“8 

k  —  2.6  ■  nr6 

4.5  •  10~6 

|.xj,  |  v| :  #  of  elements  in  input,  output 

h:  #  of  components  in  linear  function  7r  (§2.2) 

5:  #  of  variables  in  constraint  set  (§2.1) 

X:  #  of  constraints  in  constraint  set  (§2.1) 
l  =  3:  #  of  high-order  PCP  queries  in 
GINGER  (§A.2,  §A.3) 

(!  =  7:  #  of  high-order  PCP  queries  in 
PEPPER  (§ A.  1) 

p  =  70:  #  of  PCP  reps,  in  base  scheme  (§A.l) 

/3:  batch  size  (#  of  instances)  (§2.3) 

e:  cost  of  encrypting  an  element  in  F 

d:  cost  of  decrypting  an  encrypted  element 

/:  cost  of  multiplying  in  F 

h :  cost  of  ciphertext  add  plus  multiply 

c:  cost  to  generate  192-bit  pseudorandom  # 

|p  | :  length  of  an  element  in  F 

|£|:  length  of  an  encrypted  element  in  F 


Figure  2 — High-order  costs  and  error  in  GINGER,  compared  to  its  base  (PEPPER  [45]),  for  a  computation  represented  as  x  constraints 
over  s  variables  (§2.1).  The  soundness  error  depends  on  field  size  (Appendix  A.2);  the  table  assumes  |F|  =  2128.  Many  of  the 
cryptographic  costs  enter  through  the  commitment  protocol  (see  Section  2.3  or  Figure  12);  Section  6  quantifies  the  parameters.  The 
“PCP”  row  include  the  consistency  query  and  check.  The  network  costs  slightly  underestimate  by  not  including  query  responses. 


ity  test  passes  with  probability  <7/9  (though  fascinat¬ 
ing,  this  result  is  inconveniently  weak  in  our  context). 

Our  analysis,  detailed  in  Appendix  A.2,  establishes 
that  the  commitment  protocol  binds  the  prover  to  a  func¬ 
tion  that  is  extremely  close  to  linear  (otherwise,  the 
prover  could  break  the  semantic  security  of  the  homo¬ 
morphic  encryption  used  by  GINGER  and  PEPPER).  This 
results  in  the  PCP  soundness  error  improving  from  7 /9 
to  k,  where  k  ss  4//l  / |F| ;  this  analysis  does  not  depend 
on  linearity  tests,  so  they  can  be  dropped. 

The  soundness  error  is  somewhat  low  by  crypto¬ 
graphic  standards,  but  in  practice,  a  failure  rate  (when 
the  prover  is  malicious)  of  1  in  200,000  is  reasonable. 

A  further  optimization.  GINGER  reuses  some  queries 
across  the  quadratic  correction  and  circuit  tests;  this  re¬ 
finement  is  detailed  and  justified  in  Appendix  A. 3. 

Savings.  Most  significantly,  V  can  take  advantage  of  the 
lower  soundness  error  to  run  p  =  1  instead  of  p  =  70 
repetitions  of  the  PCP  protocol.  Also,  per  repetition, 
V’s  work  to  generate  pseudorandom  queries  decreases 
by  3/5  (2/5  coming  from  the  elimination  of  linearity 
tests  and  1  /5  from  reusing  queries).  These  gains  are  de¬ 
picted  in  Figure  2,  most  notably  in  the  reduction  from 
p-  (!  «  500  to  £  =  3  total  PCP  queries. 

The  total  savings  for  the  verifier  depend  on  the  relative 
cost  of  pseudorandom  number  generation  (encapsulated 
by  c)  and  encryption  (encapsulated  by  e).  These  savings 
show  up  in  /3*,  the  minimum  batch  size  (§2.3)  at  which 
V  gains  from  outsourcing.  As  shown  in  Section  6.1,  the 
reduction  in  (3*  can  be  several  orders  of  magnitude  (when 
e  is  small).  Finally,  taking  \p\  =  128  bits  and  |£|  =  2  • 
1024  bits,  the  savings  in  network  costs  are  1-2  orders  of 


magnitude  (holding  /3  constant). 

4  Broadening  the  space  of  computations 

GINGER  extends  to  computations  over  floating-point 
fractional  quantities  and  to  a  restricted  general-purpose 
programming  model  that  includes  inequality  tests,  log¬ 
ical  expressions,  conditional  branching,  etc.  To  do  so, 
GINGER  maps  computations  to  the  constraint-over- finite- 
field  formalism  (§2.1),  and  thus  the  core  protocol  in  Sec¬ 
tion  3  applies.  In  fact,  our  techniques3  apply  to  the  many 
protocols  that  use  the  constraint  formalism  or  arithmetic 
circuits.  Moreover,  we  have  implemented  a  compiler  (de¬ 
rived  from  Fairplay’s  [39])  that  transforms  high-level 
computations  first  into  constraints  and  then  into  verifier 
and  prover  executables. 

The  challenges  of  representing  computations  as  con¬ 
straints  over  finite  fields  include:  the  “true  answer”  to  the 
computation  may  live  outside  of  the  field;  sign  and  or¬ 
dering  in  finite  fields  interact  in  an  unintuitive  fashion; 
and  constraints  are  simply  equations,  so  it  is  not  obvi¬ 
ous  how  to  represent  comparisons,  logical  expressions, 
and  control  flow.  To  explain  ginger’s  solutions,  we  first 
present  an  abstract  framework  that  illustrates  how  GIN¬ 
GER  broadens  the  set  of  computations  soundly  and  how 
one  can  apply  the  approach  to  further  computations. 

Framework  to  map  computations  to  constraints.  To 

map  a  computation  'I'  over  some  domain  D  (such  as  the 
integers,  Z,  or  the  rationals,  Q)  to  equivalent  constraints 
over  a  finite  field,  the  programmer  or  compiler  performs 

3We  suspect  that  many  of  the  individual  techniques  are  known.  How- 
ever,  when  the  techniques  combine,  the  material  is  surprisingly  hard 
to  get  right,  so  we  will  delve  into  (excruciating)  detail,  consistent  with 
our  focus  on  built  systems. 
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three  steps,  as  illustrated  and  described  below: 

(Cl)  (C2) 

'I' over  Z)  - ^  vp  over  U  - »•  (/('I')overF 

(C3) 

C  over  F 

Cl  Bound  the  computation.  Define  a  set  U  CD  and  re¬ 
strict  the  input  to  'I'  such  that  the  output  and  interme¬ 
diate  values  stay  in  U. 

C2  Represent  the  computation  faithfully  in  a  suitable  fi¬ 
nite  field.  Choose  a  finite  field,  F,  and  a  map  6:  U  — ► 
F  such  that  computing  6 ( 'F )  over  0(U)  C  F  is  iso¬ 
morphic  to  computing  'F  over  U.  (By  “0(\F)”,  we 
mean  'F  with  all  inputs  and  literals  mapped  by  0.) 

C3  Transform  the  finite  field  version  of  the  computation 
into  constraints.  Write  a  set  of  constraints  over  F  that 
are  equivalent  (in  the  sense  of  Section  2.1)  to  0(31'). 

4.1  Signed  integers  and  floating-point  rationals 

We  now  instantiate  Cl  and  C2  for  integer  and  rational 
number  computations;  the  next  section  addresses  C3. 

Consider  m  x  m  matrix  multiplication  over  (V-bit 
signed  integers.  For  step  Cl,  each  term  in  the  output, 
Sl'Li  AjkBkj,  has  m  additions  of  2/V-bit  subterms  so  is 
contained  in  [— m  ■  22N~l,tn  ■  22A,_1);  this  is  our  set  U. 

For  step  C2,  take  F  =  Z /p  (the  integers  mod  a  prime 
p,  to  be  chosen  shortly)  and  define  0:  U  —y  h/p  as 
9{u)  =  u  mod  p.  Observe  that  0  maps  negative  integers 
to  {SrL  ^r-,  ■  ■  ■  ,p  —  1}.  analogous  to  how  processors 
represent  negative  numbers  with  a  1  in  the  most  signifi¬ 
cant  bit  (this  technique  is  standard  [17,  50]).  Of  course, 
addition  and  multiplication  in  1/p  do  not  “know”  when 
their  operands  are  negative.  Nevertheless,  the  computa¬ 
tion  over  Z Ip  is  isomorphic  to  the  computation  over  \J , 
provided  that  |Z/p|  >  \U\  (as  shown  in  Appendix  B). 
Thus,  for  the  given  (7,  we  require  p  >  m  ■  22N .  Note  that 
a  larger  p  brings  larger  costs  (see  Figure  2),  so  there  is  a 
three-way  trade-off  among  p,  m,  N. 

We  now  turn  to  rational  numbers.  For  step  Cl,  we  re¬ 
strict  the  inputs  as  follows:  when  written  in  lowest  terms, 
their  numerators  are  (Na  +  l)-bit  signed  integers,  and 
their  denominators  are  in  {1, 2, 22, 23, . . . ,  2Nb}.  Note 
that  such  numbers  are  (primitive)  floating-point  num¬ 
bers:  they  can  be  represented  as  a  ■  2~q ,  so  the  decimal 
point  floats  based  on  q.  Now,  for  m  x  m  matrix  multiplica¬ 
tion,  the  computation  does  not  “leave”  U  =  { ajb :  \a\  < 
2 N«,b  €  { 1,2, 22, 23, . . . ,  2^}},  for  N'a  =  2 Na  +  2 :Nb  + 
log2  in  and  N'b  =  2 A),  (shown  in  Appendix  B). 

For  step  C2,  we  take  F  =  Q/p,  the  quotient  field  of 
Z /p.  Take  0(|)  =  (a  mod  p,  b  mod  p).  For  any  1/cQ, 
there  is  a  choice  of  p  such  that  the  mapped  computation 
over  Q/p  is  isomorphic  to  the  original  computation  over 


Q  (shown  in  Appendix  B).  For  our  U  above,  p  >  (m  + 

l)2  •  24(Na+Nb')  suffices. 

Limitations  and  costs.  To  understand  the  limitations 
of  ginger’s  floating-point  representation,  consider  the 
number  a  ■  2~q,  where  \a\  <  2n°  and  \q\  <  Nq. 

To  represent  this  number,  the  IEEE  standard  requires 
roughly  Na  +  log  Nq  bits  [29]  while  GINGER  requires 
2  •  (ma x(Na,Nq)  +  1)  bits  (shown  in  Appendix  B).  As 
a  result,  ginger’s  range  is  vastly  more  limited:  with  64 
bits,  the  IEEE  standard  can  represent  numbers  on  the  or¬ 
der  of  21023  and  2-1022  (with  Na  =  53  bits  of  precision) 
while  64  bits  buys  GINGER  only  numbers  on  the  order  of 
232  and  2  32  (with  Na  =  32).  Moreover,  unlike  the  IEEE 
standard,  GINGER  does  not  support  a  division  operation 
or  rounding. 

However,  comparing  ginger’s  floating-point  repre¬ 
sentation  to  its  integer  representation,  the  extra  costs  are 
not  terrible.  First,  the  prover  and  verifier  take  an  ex¬ 
tra  pass  over  the  input  and  output  (for  implementation 
reasons;  see  Appendix  B  for  details).  Second,  a  larger 
prime  p  is  required.  For  example,  m  x  m  matrix  mul¬ 
tiplication  with  32-bit  integer  inputs  requires  p  to  have 
at  least  log2  m  +  64  bits;  if  the  inputs  are  rationals  with 
Na  =  Nq  =  32,  then  p  requires  2  log2(m  +  1)  +  256  bits. 
Roughly  speaking,  the  end-to-end  costs  are  3  x  those  of 
the  integers  case  (see  Section  6.2).  Of  course,  the  ac¬ 
tual  numbers  depend  on  the  computation.  (Our  compiler 
computes  suitable  bounds  with  static  analysis.) 

4.2  General-purpose  program  constructs 

Case  study:  branch  on  order  comparison.  We  now  il¬ 
lustrate  C3  with  a  case  study  of  a  computation,  >F,  that 
includes  a  less-than  test  and  a  conditional  branch;  pseu¬ 
docode  for  F  is  in  Figure  3.  For  clarity,  we  will  restrict 
'F  to  signed  integers;  handling  rational  numbers  requires 
additional  mechanisms  (see  Appendix  C). 

How  can  we  represent  the  test  X\  <  x2  using  con¬ 
straint  equations ?  The  solution  is  to  use  special  range 
constraints  that  decompose  a  number  into  its  bits  to  test 
whether  it  is  in  a  given  range;  in  this  case,  C<,  depicted 
in  Figure  3,  tests  whether  e  =  0{x\)  —  0{xf)  is  in  the 
“negative”  range  of  h/p  (see  Section  4.1).  Now,  under 
the  input  restriction  xi  —  x2  £  U,  C<  is  satisfiable  if  and 
only  if  x\  <  x2  (shown  in  Appendix  C).  Analogously,  we 
can  construct  C>=  that  is  satisfiable  if  and  only  if  x\  >  x2. 

Finally,  we  introduce  a  0/1  variable  M  that  encodes 
a  choice  of  branch,  and  then  arrange  for  M  to  “pull  in” 
the  constraints  of  that  branch  and  “exclude”  those  of  the 
other.  (Note  that  the  prover  need  not  execute  the  untaken 
branch.)  Figure  3  depicts  the  complete  set  of  constraints, 
(A[,;  these  constraints  are  satisfiable  if  and  only  if  the 
prover  correctly  computes  T  (shown  in  Appendix  C). 
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^  : 

r  fio(i-Bo) 

Bi(2-Bi) 

=  0,  ' 
=  0, 

f  M{C<},  ) 

if  (XI  <  X2) 

Y  =  3 

C<  =  < 

1  M(Y  —  3)  =  0,  ( 

■1  (1 

else 

Bn_2(2n~2  -  Bn_2) 

=  0, 

{  (1  —  M){Y  —  4)  =  0  J 

Y  =  4 

{  fl(X,)  -  0(X2)  -  (p  -  2»->)  -  £f=-2£, 

=  0  , 

Figure  3 — Pseudocode  for  our  case  study  of  \I/,  and  corresponding  constraints  \I/’s  inputs  are  signed  integers  xi,X2',  per  steps 
Cl  and  C2  (§4.1),  we  assume  x\  —  X2  €  U  C  [— 2Ar_1,2iv_1),  where p  >  2N .  The  constraints  C<  test  x\  <  X2  by  testing  whether  the 
bits  of  9{x  1)  —  9(x 2)  place  it  in  [p  —  2 N~l,p).  M{C}  means  multiplying  all  constraints  in  C  by  M  and  then  reducing  to  degree-2. 


Logical  expressions  and  conditionals.  Besides  order 
comparisons  and  if-else,  GINGER  can  represent  ==,  &&, 
and  I  I  as  constraints.  An  interesting  case  is  !  =:  we  can 
represent  Z1 !  =Z2  with  {M  ■  {Z\  —  Zfi)  —  1  =0}  because 
this  constraint  is  satisfiable  when  ( Z\  —  Z2)  has  a  multi¬ 
plicative  inverse  and  hence  is  not  zero.  These  constructs 
and  others  are  detailed  in  Appendix  D. 

Limitations  and  costs.  We  compile  a  subset  of  SFDL, 
the  language  of  the  Fairplay  compiler  [39],  Thus,  our 
limitations  are  essentially  those  of  SFDL;  notably,  loop 
bounds  have  to  be  known  at  compile  time. 

How  efficient  is  our  representation?  The  program  con¬ 
structs  above  mostly  have  concise  constraint  representa¬ 
tions.  Consider,  for  instance,  compl==comp2;  the  equiv¬ 
alent  constraint  set  C  consists  of  the  constraints  that  rep¬ 
resent  compl,  the  constraints  that  represent  comp2,  and 
an  additional  constraint  to  relate  the  outputs  of  compl 
and  comp2.  Thus,  C  is  the  same  size  as  its  two  compo¬ 
nents,  as  one  would  expect. 

However,  two  classes  of  computations  are  costly.  First, 
inequality  comparisons  require  variables  and  a  con¬ 
straint  for  every  bit  position;  see  Figure  3.  Second,  the 
constraints  for  if-else  and  I  I ,  as  written,  seem  to  be 
degree-3;  notice,  for  instance,  the  M{C}  in  Figure  3.  To 
be  compatible  with  the  core  protocol,  these  constraints 
must  be  rewritten  to  be  degree-2  (§2.1),  which  carries 
costs.  Specifically,  if  C  has  s  variables  and  \  constraints, 
an  equivalent  degree-2  representation  of  M{C}  has  ,v  +  \ 
variables  and  2  •  \  constraints  (shown  in  Appendix  D). 

5  Parallelization  and  implementation 

Many  of  ginger’s  remaining  costs  are  in  the  crypto¬ 
graphic  operations  in  the  commitment  protocol  (see  Ap¬ 
pendix  A.l).  To  address  these  costs,  we  distribute  the 
prover  over  multiple  machines,  leveraging  ginger’s  in¬ 
herent  parallelism.  We  also  implement  the  prover  and 
verifier  on  GPUs,  which  raises  two  questions.  (1)  Isn’t 
this  just  moving  the  problem?  Yes,  and  this  is  good: 
GPUs  are  optimized  for  the  types  of  operations  that  bot¬ 
tleneck  GINGER.  (2)  Why  do  we  assume  that  the  verifier 
has  a  GPU?  Desktops  are  more  likely  than  servers  to  have 
GPUs,  and  the  prevalence  of  GPUs  is  increasing.  Also, 
this  setup  models  a  future  in  which  specialized  hardware 
for  cryptographic  operations  is  common. 


Parallelization.  To  distribute  ginger’s  prover,  we  run 
multiple  copies  of  it  (one  per  host),  each  copy  receiving 
a  fraction  of  the  batch  (Section  2.3).  In  this  configura¬ 
tion,  the  provers  use  the  Open  MPI  [2]  message-passing 
library  to  synchronize  and  exchange  data. 

To  further  reduce  latency,  each  prover  offloads  work 
to  a  GPU  (see  also  [49]  for  an  independent  study  of  GPU 
hardware  in  the  context  of  [21]).  We  exploit  three  levels 
of  parallelism  here.  First,  the  prover  performs  a  cipher- 
text  operation  for  each  component  in  the  commitment 
vector  (§2.3);  each  operation  is  (to  first  approximation) 
separate.  Second,  each  operation  computes  two  indepen¬ 
dent  modular  exponentiations  (the  ciphertext  of  an  ElGa- 
mal  encryption  has  two  elements).  Third,  modular  expo¬ 
nentiation  itself  admits  a  parallel  implementation  (each 
input  is  a  multiprecision  number  encoded  in  multiple  ma¬ 
chine  words).  Thus,  in  our  GPU  implementation,  a  group 
of  CUDA  [1]  threads  computes  each  exponentiation. 

We  also  parallelize  the  verifier’s  encryption  work  dur¬ 
ing  the  commitment  phase  (§2.3),  using  the  approach 
above  plus  an  optimization:  the  verifier’s  exponentiations 
are  fixed  base,  letting  us  memoize  intermediate  squares. 
We  implement  exponentiations  for  the  prover  and  veri¬ 
fier  with  the  libgpucrypto  library  of  SSLShader  [36], 
modified  to  implement  the  memoization. 


Implementation  details.  Our  compiler  consists  of  two 
stages,  which  a  future  publication  will  detail.  The  front- 
end  compiles  a  subset  of  Fairplay’s  SFDL  [39]  to  con¬ 
straints;  it  is  derived  from  Fairplay  and  is  implemented 
in  5294  lines  of  Java,  starting  from  Fairplay’s  3886  lines 
(per  [51]).  The  back-end  transforms  constraints  into  C++ 
code  that  implements  the  verifier  and  prover  and  then  in¬ 
vokes  gcc;  this  component  is  1 105  lines  of  Python  code. 

For  efficiency,  PEPPER  [45]  introduced  specialized 
PCP  protocols  for  certain  computations.  For  some  exper¬ 
iments  we  use  specialized  PCPs  in  GINGER  also;  in  these 
cases  we  write  the  prover  and  verifier  manually,  which 
typically  requires  a  few  hundred  lines  of  C++.  Automat¬ 
ing  the  compilation  of  specialized  PCPs  is  future  work. 

The  verifier  and  prover  are  separate  processes  that  ex¬ 
change  data  using  Open  MPI  [2],  GINGER  uses  the  El- 
Gamal  cryptosystem  [23]  with  1024-bit  keys. 
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ginger's  protocol  refinements  reduce  per-instance  network  costs  by  25-30x  (to  hundreds  of  KBs  for  the  computations 
we  study),  prover  CPU  costs  by  about  10-14%  (leaving  them  still  high),  and  break-even  batch  size  (/?*)  by  about  4x . 
With  accelerated  encryption  GINGER  breaks  even  from  outsourcing  short  computations  at  small  batch  sizes;  for  400  x  400 
matrix  multiplication,  the  verifier  gains  from  outsourcing  at  a  batch  size  of  20  (tens  of  seconds  of  computation). 

Rational  arithmetic  costs  roughly  3x  integer  arithmetic  under  GINGER  (but  much  more  than  native  floating-point). 
Parallelizing  results  in  near-linear  reduction  in  the  prover’s  latency. 


§6.1 

§6.1 

§6.2 

§6.3 


Figure  4 — Summary  of  main  evaluation  results. 
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Figure  5 — Benchmark  computations,  s  is  the  number  of  constraint  variables;  s  affects  n,  which  is  the  size  of  U’s  queries  and  of  P’s 
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input  and  the  set  of  strings.  Bisection  method  refers  to  root-finding  via  bisection:  both  V  and  P  hold  a  degree-2  polynomial  in  m 
variables,  the  input  is  two  m-e lement  endpoints  that  bracket  a  root,  and  the  output  is  a  small  interval  that  contains  the  root. 


6  Experimental  evaluation 

Our  evaluation  answers  the  following  questions: 

•  What  is  the  effect  of  the  protocol  refinements  (§3)? 

•  What  are  the  costs  of  supporting  rational  numbers  and 
the  additional  program  structures  (§4)? 

•  What  is  ginger’s  speedup  from  parallelizing  (§5)? 
Figure  4  summarizes  the  results. 

We  use  six  benchmark  computations,  summarized  in 
Figure  5  (Appendix  E  has  details).  For  bisection  method 
and  degree-2  polynomial  evaluation,  V  and  P  were  pro¬ 
duced  by  our  compiler;  for  the  other  computations,  we 
use  tailored  encodings  (see  Section  5).  We  implemented 
and  analyzed  other  computations  (e.g.,  edit  distance  and 
circle  packing)  but  found  that  V  gained  from  outsourcing 
only  at  implausibly  large  batch  sizes. 

Method  and  setup.  We  measure  latency  and  comput¬ 
ing  cycles  used  by  the  verifier  and  the  prover,  and  the 
amount  of  data  exchanged  between  them.  We  account 
for  the  prover’s  cost  in  per-instance  terms.  Because  the 
verifier  amortizes  costs  over  a  batch  (§2.3),  we  focus  on 
the  break-even  batch  size,  (3* :  the  batch  size  at  which  the 
verifier’s  CPU  cost  from  GINGER  equals  the  cost  of  com¬ 
puting  the  batch  locally.  We  measure  local  computation 
using  implementations  built  on  the  GMP  library  (except 
for  matrix  multiplication  over  rationals,  where  we  use  na¬ 
tive  floating-point). 

For  each  result  that  we  report,  we  run  at  least  three  ex¬ 
periments  and  take  the  averages  (the  standard  deviations 
are  always  within  5%  of  the  means).  We  measure  CPU 
time  using  getrusage,  latency  using  PAPFs  real  time 


counter  [3],  and  network  costs  by  recording  the  number 
of  application-level  bytes  transferred. 

Our  experiments  use  a  cluster  at  the  Texas  Advanced 
Computing  Center  (TACC).  Each  machine  is  configured 
identically  and  runs  Linux  on  an  Intel  Xeon  processor 
E5540  2.53  GHz  with  48GB  of  RAM.  Experiments  with 
GPUs  use  machines  with  an  NVIDIA  Tesla  M2070.  Each 
GPU  has  448  CUDA  cores  and  6GB  of  memory. 

Validating  the  cost  model.  We  will  sometimes  predict 
(3*,  V’s  costs,  and  P’s  costs  by  using  our  cost  model 
(Figure  2),  so  we  now  validate  this  model.  We  run  mi¬ 
crobenchmarks  to  quantify  the  model’s  parameters — e  is 
reported  in  this  section;  Appendix  E  quantifies  the  other 
parameters — and  then  compare  the  parameterized  model 
to  ginger’s  measured  performance,  ginger’s  empiri¬ 
cal  results  are  at  most  2%-15%  more  than  are  predicted 
by  the  model.  However,  local  computation  costs  about 
1.2-A.O  times  more  than  is  predicted;  we  think  that  the 
divergence  results  from  adverse  caching  effects  that  in¬ 
crease  the  cost  of  a  multiplication.  Thus,  we  expect  the 
verifier  to  break  even  at  batch  sizes  that  are  about  a  factor 
of  1 .2 — 4.0  smaller  than  predicted  by  the  model. 

6.1  The  effect  of  ginger’s  protocol  refinements 

We  begin  with  m  x  m  matrix  multiplication  (m  = 

100.200)  and  degree-3  polynomial  evaluation  (m  = 

100.200) ,  and  batch  size  of  f3  =  5000.  We  report  per- 
instance  network  and  CPU  costs:  the  total  network  and 
CPU  costs  over  the  batch,  divided  by  f3. 

Figure  6  depicts  network  costs.  For  matrix  multipli¬ 
cation,  these  are  about  the  same  as  the  cost  to  send  the 


matrix  mult  matrix  mult  d-3  poly  eval  d-3  poly  eval 
(m=100)  (m=200)  (m=100)  (m=200) 


Figure  6 — Per-instance  network  costs  of  GINGER  and  its  base 
(PEPPER  [45]),  compared  to  the  size  of  the  inputs  and  outputs. 
At  this  batch  size  (J3  =  5000),  ginger's  refinements  reduce 
per-instance  network  costs  by  a  factor  of  25-30  compared  to 
PEPPER,  ginger’s  network  costs  here  are  hundreds  of  KB  or 
less.  The  y-axis  is  log-scaled. 
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Figure  7— 

-Break-even  batch  sizes 

(/3*)  and  predicted  running 

times  of  prover  and  verifier  at  /?  =  /3* ,  for  matrix  multiplication 
(m  =  400).  under  three  models  of  the  encryption  cost.  The 
verifier’s  per-instance  work  is  not  depicted  because  it  equals  the 
local  running  time,  by  definition  of  ft* .  The  local  running  time 
is  high  in  part  because  the  local  implementation  uses  GMP. 

inputs  and  receive  the  outputs;  for  polynomial  evalua¬ 
tion,  these  are  about  10  times  the  size  of  the  inputs  and 
outputs.  Also,  GINGER  improves  on  PEPPER  by  20-30x . 

In  this  experiment,  ginger’s  prover  incurs  about  10- 
14%  less  CPU  time  compared  to  PEPPER  (estimated  us¬ 
ing  a  cost  model  from  [45])  but  still  takes  tens  of  min¬ 
utes  per-instance;  this  is  obviously  a  lot,  but  we  reduce 
latency  by  parallelizing  (§6.3).  For  this  computation  and 
at  this  batch  size  (/?  =  5000),  ginger’s  verifier  takes  a 
few  hundreds  of  milliseconds  per-instance,  less  than  lo¬ 
cally  computing  using  our  baseline  of  GMP. 

Amortizing  the  verifier’s  costs.  Batching  is  both  a  lim¬ 
itation  and  a  strength  of  GINGER:  ginger’s  verifier  must 
batch  to  gain  from  outsourcing  but  can  batch  to  drive  per- 
instance  overhead  arbitrarily  low.  Nevertheless,  we  want 
break-even  batch  sizes  (/?*)  to  be  as  small  as  possible. 
But  j3*  mostly  depends  on  e,  the  cost  of  encryption  (Fig¬ 
ure  2),  because  after  our  refinements  the  verifier’s  main 
burden  is  creating  Enc (pk,  r )  (see  §2.3),  the  cost  of  which 
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Figure  8 — Predicted  running  times  of  ginger’s  verifier  and 
prover  for  matrix  multiplication  (m  =  100),  under  integer  and 
floating-point  inputs,  at  f)  =  4300  (the  break-even  batch  size 
for  this  computation  over  integers).  The  “local”  row  refers  to 
GMP  arithmetic  for  Z  and  native  floating-point  arithmetic  for 
Q.  Handling  rationals  costs  GINGER  roughly  3x  more  than 
handling  integers,  but  both  are  still  far  from  native. 

computation  (T1)  #  Boolean  gates  (est.)  #  constraint  vars. 

m-Hamming  dist.  1.3  ■  106  2  ■  104 

bisection  method  3.0  ■  108  1528 

Figure  9 — ginger’s  constraints  compared  to  Boolean  circuits, 
for  m- Hamming  distance  (in  =  100)  and  bisection  method 
(m  =  25).  The  Boolean  circuits  are  estimated  using  the  un¬ 
modified  Fairplay  [39]  compiler,  ginger’s  constraints  are  not 
concise  but  are  far  more  so  than  Boolean  circuits. 

amortizes  over  the  batch. 

What  values  of  e  make  sense?  We  consider  three  sce¬ 
narios:  (1)  the  verifier  uses  a  CPU  for  encryptions,  (2) 
the  verifier  offloads  encryptions  to  a  GPU,  and  (3)  the 
verifier  has  special-purpose  hardware  that  can  only  per¬ 
form  encryptions.  (See  Section  5  for  motivation.)  Under 
scenario  (1),  we  measure  e  =  72.1  fis  on  a  2.5  GHz  CPU. 
Under  scenario  (3),  we  take  e  =  0/is.  What  about  sce¬ 
nario  (2)?  Our  cost  model  concerns  CPU  costs,  so  we 
need  an  exchange  rate  between  GPU  and  CPU  exponen- 
tations.  We  make  a  crude  estimate:  we  measure  the  num¬ 
ber  of  encryptions  per  second  achievable  on  an  NVIDIA 
Tesla  M2070  (which  is  180,000)  and  on  an  Intel  2.5 
GHz  CPU  (which  is  13,700),  normalize  by  the  dollar 
cost  of  the  chips,  and  obtain  that  their  throughput-per- 
dollar  ratio  is  1.8  x.  We  thus  (very  conservatively)  take 
e  =  72.1/1.8  =  40/zs. 

We  plug  these  three  values  of  e  into  the  cost  model  in 
Figure  2,  set  the  cost  under  GINGER  equal  to  the  cost  of 
local  computing,  and  solve  for  /?*.  The  values  of  /?*  are 
4150  (CPU),  2300  (crude  GPU  estimate),  and  20  (crypto 
hardware).  We  also  use  the  model  to  predict  V’s  and  P’s 
costs  at  /?*,  under  PEPPER  and  GINGER.  Figure  7  summa¬ 
rizes.  GINGER  is  very  sensitive  to  the  value  of  e  because 
its  refinements  have  eliminated  many  of  the  other  costs. 
Moreover,  the  aggregate  verifier  computing  time  drops 
significantly  under  all  three  cost  models.  The  prover’s 
per-instance  work  is  mostly  unaffected,  but  as  the  batch 
size  decreases,  so  does  its  aggregate  work. 
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Figure  10 — Latency  speedup  observed  by  ginger's  verifier  when  the  prover  is  parallelized.  We  run  with  m  =  100,/?  =  150  for 
matrix  multiplication  and  degree-3  polynomial  evaluation;  m  =  100,  /?  =  1500  for  degree-2  polynomial  evaluation;  m  =  100,  /?  = 
15  for  m-Hamming  distance;  and  m  =  25,/?  =  15  for  bisection  method,  ginger’s  prover  achieves  near-linear  speedups  except 
when  the  problem  sizes  are  small  and  hence  the  overhead  from  parallelizing  is  significant  (e.g.,  degree-2  polynomial  evaluation). 


6.2  Evaluating  GINGER’S  computational  model 

To  understand  the  costs  of  the  floating-point  representa¬ 
tion  (§4.1),  we  compare  it  to  two  baselines;  ginger’s 
signed  integer  representation  and  the  computation  exe¬ 
cuted  locally,  using  the  CPU’s  floating  point  unit.  Our 
benchmark  application  is  matrix  multiplication  (m  = 
100).  Figure  8  details  the  comparison. 

We  also  consider  ginger’s  general-purpose  program 
constructs  (§4).  Our  baseline  is  Boolean  circuits  (we  are 
unaware  of  efficient  arithmetic  representations  of  these 
constructs).  We  compare  the  number  of  Boolean  circuit 
gates  and  the  number  of  ginger’s  arithmetic  constraint 
variables,  since  these  determine  the  proving  and  verify¬ 
ing  costs  under  the  respective  formalisms  (see  [5,  45]). 
Taken  individually,  ginger’s  constructs  (<=,  &&,  etc.) 
are  the  same  cost  or  more  than  those  of  Boolean  cir¬ 
cuits  (e.g.,  I  I  introduces  auxiliary  variables).  However, 
Boolean  circuits  are  in  general  far  more  verbose;  they 
represent  quantities  by  their  bits  (which  GINGER  does 
only  when  computing  inequalities).  Figure  9  gives  a 
rough  end-to-end  comparison. 

6.3  Scalability  of  the  parallel  implementation 

To  demonstrate  the  scalability  of  ginger’s  paralleliza¬ 
tion,  we  run  the  prover  using  many  CPU  cores,  many 
GPUs,  and  many  machines.  We  measure  end-to-end  la¬ 
tency,  as  observed  by  the  verifier.  Figure  10  summarizes 
the  results  for  various  computations.  In  most  cases,  the 
speedup  is  near-linear. 

7  Related  work 

A  substantial  body  of  work  achieves  two  of  our  goals — 
it  is  general-purpose  and  practical — but  it  makes  strong 
assumptions  about  the  servers  (e.g.,  trusted  hardware). 
There  is  also  a  large  body  of  work  on  protocols  for 
special-purpose  computation.  We  regard  this  work  as 
orthogonal  to  our  efforts;  for  a  survey  of  this  land¬ 
scape,  see  [45].  Herein,  we  focus  on  approaches  that  are 
general-purpose  and  unconditional. 

Homomorphic  encryption  and  secure  multi-party 
protocols.  Homomorphic  encryption  (which  enables 


computation  over  ciphertext)  and  secure  multi-party  pro¬ 
tocols  (in  which  participants  compute  over  private  data, 
revealing  only  the  result  [34,  39,  52])  provide  only  pri¬ 
vacy  guarantees,  but  one  can  build  on  them  for  verifiable 
computation.  For  instance,  the  Boneh-Goh-Nissim  ho¬ 
momorphic  cryptosystem  [18]  can  be  adapted  to  evaluate 
circuits,  Groth  uses  homomorphic  commitments  to  pro¬ 
duce  a  zero-knowledge  argument  protocol  [33],  and  Ap- 
plebaum  et  al.  use  secure  multi-party  protocols  for  ver¬ 
ifying  computations  [4].  Also,  Gentry’s  fully  homomor¬ 
phic  encryption  [27]  has  engendered  protocols  for  verifi¬ 
able  non-interactive  computation  [20,  24,  26].  However, 
despite  striking  improvements  [28,  42,  47],  the  costs  of 
hiding  inputs  (among  other  expenses)  prevent  any  of  the 
aforementioned  verified  computation  schemes  from  get¬ 
ting  close  to  practical  (even  by  our  relaxed  standards). 

PCPs,  argument  systems,  and  interactive  proofs.  Ap¬ 
plying  proof  systems  to  verifiable  computation  is  stan¬ 
dard  in  the  theory  community  [5-7,  10,  15,  32,  37,  38, 
41],  and  the  asymptotics  continue  to  improve  [13,  14,  22, 
43].  However,  none  of  this  work  has  paid  much  attention 
to  building  systems. 

Very  recently,  researchers  have  begun  to  explore  using 
this  theory  for  practical  verified  outsourced  computation. 
In  a  recent  preprint,  Ben-Sasson  et  al.  [12]  investigate 
when  PCP  protocols  might  be  beneficial  for  outsourcing. 
Since  many  of  the  protocols  require  representing  compu¬ 
tations  as  constraints,  Ben-Sasson  et  al.  [11]  study  im¬ 
proved  reductions  to  constraints  from  a  RAM  model  of 
computation.  And  Gennaro  et  al.  [25]  give  a  new  charac¬ 
terization  of  NP  to  provide  asymptotically  efficient  argu¬ 
ments  without  using  PCPs. 

However,  as  far  as  we  know,  only  two  research  groups 
have  made  serious  efforts  toward  practical  systems.  Our 
previous  work  [44,  45]  built  upon  the  efficient  argument 
system  of  Ishai  et  al.  [35].  In  contrast,  Cormode,  Mitzen- 
macher,  and  Thaler  [21]  (hereafter,  CMT)  built  upon  the 
protocol  of  Goldwasser  et  al.  [31],  and  a  follow-up  effort 
studies  a  GPU-based  parallel  implementation  [49]. 

Comparison  of  GINGER  and  CMT  [21,  49].  We 

compared  three  different  implementations:  CMT-native, 
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Figure  11 — CMT  [21]  compared  to  GINGER,  in  terms  of  amor¬ 
tized  CPU  and  network  costs  (ginger’s  total  costs  are  divided 
by  a  batch  size  of  ,3=5000  instances),  for  m  x  m  matrix  mul¬ 
tiplication.  CMT-native  uses  native  data  types  but  is  restricted 
to  small  problem  sizes  and  domains.  CMT-GMP  uses  the  GMP 
library  for  multi-precision  arithmetic  (as  does  GINGER). 

CMT-GMP ,  and  GINGER.  CMT-native  refers  to  the  code 
and  configuration  released  by  Thaler  et  al.  [49];  it  works 
over  a  small  field  and  thereby  exploits  highly  efficient 
machine  arithmetic  but  restricts  the  inputs  to  the  compu¬ 
tation  unrealistically  (see  Section  4.1).  CMT-GMP  refers 
to  an  implementation  based  on  CMT-native  but  modified 
by  us  to  use  the  GMP  library  for  multi-precision  arith¬ 
metic;  this  allows  more  realistic  computation  sizes  and 
inputs,  as  well  as  rational  numbers. 

We  perform  two  experiments  using  m  x  m  matrix  mul¬ 
tiplication.  Our  testbed  is  the  same  as  in  Section  6.  In  the 
first  one,  we  run  with  m  =  256  and  integer  inputs.  For 
CMT-GMP  and  GINGER,  the  inputs  are  32-bit  unsigned 
integers,  and  the  prime  (the  field  modulus)  is  128  bits. 
For  CMT-native,  the  prime  is  261  —  1.  In  the  second  ex¬ 
periment,  m  is  128,  the  inputs  are  rational  numbers  (with 
Na  =  Ni,  =  32;  see  Section  4.1),  the  prime  is  320  bits, 
and  we  experiment  only  with  CMT-GMP  and  GINGER. 

We  measure  total  CPU  time  and  network  cost;  for 
CMT,  we  measure  “network”  traffic  by  counting  bytes 
(the  CMT  verifier  and  prover  run  in  the  same  process 
and  hence  the  same  machine).  Each  reported  datum  is  an 
average  over  3  sample  runs;  there  is  little  experimental 
variation  (less  than  5%  of  the  means). 

Figure  1 1  depicts  the  results.  CMT  incurs  a  significant 
penalty  when  moving  from  native  to  GMP  (and  hence 
to  realistic  problem  sizes).  Comparing  CMT-GMP  and 
GINGER,  the  network  and  prover  costs  are  similar  (al¬ 
though  network  costs  for  CMT  reflect  high  fixed  over¬ 
head  for  their  circuit).  The  per-instance  verifier  costs 
are  also  similar,  but  GINGER  is  batch  verifying  whereas 
CMT  does  not  need  to  do  so  (a  significant  advantage). 

A  qualitative  comparison  is  as  follows.  On  the  one 
hand,  CMT  does  not  require  cryptography,  has  better 
asymptotic  prover  and  network  costs,  and  for  some  com¬ 
putations  the  verifier  does  not  need  batching  to  gain  from 
outsourcing  [49].  On  the  other  hand,  CMT  applies  to  a 
smaller  set  of  computations:  if  the  computation  is  not  ef¬ 
ficiently  parallelizable  or  does  not  naturally  map  to  arith¬ 
metic  circuits  (e.g.,  it  has  order  comparisons  or  condi¬ 
tionality),  then  CMT  in  its  current  form  will  be  inappli¬ 


cable  or  inefficient,  respectively.  Ultimately,  GINGER  and 
CMT  should  be  complementary,  as  one  can  likely  ease  or 
eliminate  some  of  the  restrictions  on  CMT  by  incorporat¬ 
ing  the  constraint  formalism  together  with  batching  [48], 

8  Summary  and  conclusion 

This  paper  is  a  contribution  to  the  emerging  area  of 
practical  PCP-based  systems  for  unconditional  verifiable 
computation.  GINGER  has  combined  theoretical  refine¬ 
ments  (slashing  query  costs  and  network  overhead);  a 
general  computational  model  (including  fractions  and 
standard  program  constructs)  with  a  compiler;  and  a  mas¬ 
sively  parallel  implementation  that  takes  advantage  of 
modern  hardware.  Together,  these  changes  have  brought 
us  closer  to  a  truly  deployable  system.  Nevertheless, 
much  work  remains :  the  efficiency  of  the  verifier  depends 
on  special  hardware,  the  costs  for  the  prover  are  still  too 
high,  and  looping  cannot  yet  be  handled  concisely. 
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A  Efficient  arguments  with  linear  PCPs 
but  no  linearity  tests 

Whereas  previous  work  [35,  45]  established  that  the 
commitment  protocol  in  phases  2  and  3  of  PEPPER  (§2.3) 
binds  the  prover  to  a  particular  function,  there  were  no 
constraints  on  that  function.  The  principal  result  of  this 
section  is  that  the  prover  is  actually  bound  to  a  function 
that  is  linear,  or  very  nearly  so.  As  a  consequence,  we  can 
eliminate  linearity  testing  from  the  PCP  protocol.  Fur¬ 
thermore,  the  error  bound  from  one  run  of  this  modified 
PCP  protocol  is  far  stronger  (lower)  than  was  known. 

This  section  describes  the  base  protocols  (A.l),  states 
the  refinements  and  proves  their  soundness  (A. 2),  and  de¬ 
scribes  a  few  other  optimizations  (A. 3). 
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Commit+Multidecommit 

The  protocol  assumes  an  additive  homomorphic  encryption  scheme  (Gen,  Enc,  Dec)  over  a  finite  field,  F. 

Commit  phase 

Input:  Prover  holds  a  vector  w  £  F",  which  defines  a  linear  function  n :  F"  — >  F,  where  n(q)  =  (w,  q). 

1.  Verifier  does  the  following: 

•  Generates  public  and  secret  keys  (pk ,  sk)  4—  Gen(lA),  where  k  is  a  security  parameter. 

•  Generates  vector  r  £r  F"  and  encrypts  r  component-wise,  so  Enc  (pk,  r)  =  (Enc(pfc,  ri), . . . ,  Enc  (pk,  rn)). 

•  Sends  Enc  (pk,  r)  and  pk  to  the  prover. 

2.  Using  the  homomorphism  in  the  encryption  scheme,  the  prover  computes  e  4—  Enc(pfe,  7r(r))  without  learning  r.  The  prover 
sends  e  to  the  verifier. 

3.  The  verifier  computes  s  4—  Dec(sk,  e),  retaining  s  and  r. 

Decommit  phase 

Input:  the  verifier  holds  q\ , . . . ,  q^  £  F"  and  wants  to  obtain  ir(qi ),...,  7 r(^). 

4.  The  verifier  picks  p  secrets  Qi, . . . ,  aM  F  and  sends  to  the  prover  (<71, . . . ,  q^,  t),  where  t  =  r  +  aiqi  +  ■  ■  ■  +  a^q^  eF". 

5.  The  prover  returns  (a\,  02, . . . ,  a^,b),  where  a,,  b  £  F.  If  the  prover  behaved,  then  a,  =  n(qi)  for  all  i  £  [p],  and  b  =  n(t). 

6.  The  verifier  checks:  b  =  s  +  Qifli  +  •  •  •  +  a^a^.  If  so,  it  outputs  (a  1,02, ....  a ^).  If  not,  it  rejects,  outputting  _L. 

Figure  12 — The  commitment  protocol  of  PEPPER  [45],  which  generalizes  a  protocol  of  Ishai  et  al.  [35].  qi, . . . ,  q^  are  the  PCP 
queries,  and  n  is  the  size  of  the  proof  encoding.  The  protocol  is  written  in  terms  of  an  additive  homomorphic  encryption  scheme,  but 
as  stated  elsewhere  [35, 45],  the  protocol  can  be  modified  to  work  with  a  multiplicative  homomorphic  scheme,  such  as  ElGamal  [23]. 


A.1  Base  protocols 

GINGER  uses  a  linear  commitment  protocol  that  is  bor¬ 
rowed  from  PEPPER  [45];  this  protocol  is  depicted  in  Fig¬ 
ure  12.4  As  described  in  Section  2.3,  PEPPER  composes 
this  protocol  and  a  linear  PCP;  that  PCP  is  depicted  in 
Figure  13.  The  purpose  of  {70, 71, 72}  in  this  figure  is  to 
make  a  maliciously  constructed  oracle  unlikely  to  pass 
the  circuit  test;  to  generate  the  {7,},  V  multiplies  each 
constraint  by  a  random  value  and  collects  like  terms,  a 
process  described  in  [5,  13,  35,  45].  The  completeness 
and  soundness  of  this  PCP  are  explained  in  those  sources, 
and  our  notation  is  borrowed  from  [45],  Here  we  just  as¬ 
sert  that  the  soundness  error  of  this  PCP  is  e  =  (7/9)p; 
that  is,  if  the  proof  n  is  incorrect,  the  verifier  detects  that 
fact  with  probability  greater  than  1  —  e.  To  make  e  small, 
PEPPER  takes  p  =  70. 

A.2  Stronger  soundness  analysis  and  consequences 

GINGER  retains  the  (P,  V)  argument  system  of  PEP¬ 
PER  [45]  but  uses  a  modified  PCP  protocol  (depicted  in 
Figure  14)  that  makes  the  following  changes  to  the  base 
PCP  protocol  (Figure  13): 

•  Remove  the  linearity  queries  and  tests. 

•  Set  p  =  1. 

Theorem  A.l.  The  (P,  V)  described  above  is  an  argu¬ 
ment  system  with  soundness  ec  ~  -\/l/|F|.  (The  exact 
value  of  ec  depends  on  intermediate  lemmas  and  will  be 
given  at  the  end  of  the  section.) 

4Like  PEPPER,  GINGER  verifies  in  batches  (§2.3),  which  changes  the 
protocols  a  bit;  see  [45,  Appendix  C]  for  details. 


We  will  prove  this  theorem  at  the  end  of  this  section. 
To  build  up  to  the  proof,  we  first  strengthen  the  defini¬ 
tion  of  a  linear  commitment  primitive.  We  note  that  only 
the  third  property  (linearity)  in  the  definition  is  new;  the 
rest  is  taken  from  [45,  Appendix  B],  which  itself  heavily 
borrows  framing,  notation,  and  text  from  Ishai  et  al.  [35], 

Definition  A.l  (Commitment  to  a  function  with  multi¬ 
ple  decommitments  (CFMD)).  Define  a  two-phase  ex¬ 
periment  between  two  probabilistic  polynomial  time  ac¬ 
tors  ( S ,  R)  (a  sender  and  receiver,  which  correspond  to 
our  prover  and  verifier)  in  an  environment  £  that  gener¬ 
ates  F,  w  and  Q  =  (q\, . . . ,  q^).  In  the  first  phase,  the 
commit  phase,  S  has  w,  and  5  and  R  interact,  based  on 
their  random  inputs.  In  the  decommit  phase,  £  gives  Q 
to  R,  and  5  and  R  interact  again,  based  on  further  ran¬ 
dom  inputs.  At  the  end  of  this  second  phase,  R  outputs 
A  =  (ai, . . .  ,aM)  €  Fp  or  J_.  A  CFMD  meets  the  fol¬ 
lowing  properties: 

•  Correctness.  At  the  end  of  the  decommit  phase,  R 
outputs  7r(q,)  =  ( w ,  qi)  (for  all  i),  if  S  is  honest. 

•  r /.-Binding.  Consider  the  following  experiment.  The 
environment  £  produces  two  (possibly  distinct)  p- 
tuples  of  queries:  Q  =  (q and  Q  = 
(qi, . . . ,  q^).  R  and  a  cheating  S*  run  the  commit 
phase  once  and  two  independent  instances  of  the  de¬ 
commit  phase.  In  the  two  instances  R  presents  the 
queries  as  Q  and  Q,  respectively.  We  say  that  S*  wins 
binding  if  R’s  outputs  at  the  end  of  the  respective 
decommit  phases  are  A  =  (a\, . . . ,  a^)  and  A  = 
(di, . . .  ,aM),  and  for  some  i,j,  we  have  qi  =  qj  but 
a,  ^  dj.  We  say  that  the  protocol  meets  the  ^//-Binding 
property  if  for  all  £  and  for  all  efficient  S*,  the  proba- 
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The  linear  PCP  from  [5] 


Loop  p  times: 

•  Generate  linearity  queries:  Select  771,772  €r  F3  and 

2 

#4, qs  £r  F3  .  Take  q3  <r-  q\  +  qi  and  q6  t—  q\  +  qs. 

•  Generate  quadratic  correction  queries:  Select  777,77s  £r  F3 

2 

and  qw  €r  F3  .  Take  qg  <-  ( qi  ®  qs  +  qio)- 

2 

•  Generate  circuit  queries:  Select  q n  €r  F3  and  7714  £r  F3  . 
Take  qn  <-71+  <7i2  and  <7i3  f—  72  +  9i4. 

•  Issue  queries.  Send  qi, . . . ,  qu  to  oracle  7r,  getting  back 
7r(^i), . .  .,77(344). 

•  Linearity  tests:  Check  that  77(771)  +  77(772)  =  77(773)  and  that 
77(774)  +  77(775)  =  77(776).  If  not,  reject. 

•  Quadratic  correction  test:  Check  that  77(777)  ■  77 (qs)  = 
77(779)  —  77(7710).  If  not,  reject. 

•  Circuit  test:  Check  that  (77(7711)  —  77(7712))  + 

(77(343)  —  77(344))  =  —70.  If  not,  reject . 

If  V  makes  it  here,  accept. 

Figure  13 — The  linear  PCP  that  PEPPER  uses.  It  is  from  [5], 
The  notation  x  ®  y  refers  to  the  outer  product  of  two  vectors  x 
and  y  (meaning  the  vector  or  matrix  consisting  of  all  pairs  of 
components  from  the  two  vectors).  The  values  {70,71,72}  are 
described  briefly  in  the  text. 

bility  of  S*  winning  binding  is  less  than  eB.  The  proba¬ 
bility  is  taken  over  three  sets  of  independent  random¬ 
ness:  the  commit  phase  and  the  two  runnings  of  the 
decommit  phase. 

•  ^/  -Linearity.  Consider  the  same  experiment  above. 
We  say  that  S*  wins  linearity  if  R’ s  outputs  at  the 
end  of  the  respective  decommit  phases  are  A  = 
(a  1, . . . ,  aB)  and  A  =  (ai, ....  aM),  and  for  some  i,j,  k, 
we  have  qu  =  qi  +  qj  but  ak  f  a,  +  aj.  We  say  that 
the  protocol  meets  the  -linearity  property  if  for  all  £ 
and  for  all  efficient  S*,  the  probability  of  S*  winning 
linearity  is  less  than  <7  .  As  with  the  prior  property, 
the  probability  is  taken  over  three  sets  of  independent 
randomness:  the  commit  phase  and  the  two  runnings 
of  the  decommit  phase. 

Prior  work  proved  that  Commit+Multidecommit  (Fig¬ 
ure  12)  meets  the  first  two  properties  above  [45].  We  will 
now  show  that  it  also  meets  the  third  property. 

Lemma  A.l.  Commit+Multidecommit  meets  the  defini¬ 
tion  of  e/,-linearity,  with  =  1/|F|  +  es,  where  es  comes 
from  the  semantic  security  of  the  homomorphic  encryp¬ 
tion  scheme. 

Proof.  We  will  show  that  if  S*  can  systematically  cheat, 
then  an  adversary  A  could  use  S*  to  break  the  semantic 
security  of  the  encryption  scheme. 

Let  r  F"  and  Z7Z2  F  (we  use  to  mean 
“drawn  uniformly  at  random  from”).  Semantic  security 


ginger’s  PCP  protocol 

•  Generate  quadratic  correction  queries:  Select  771,772  Gr  F3 

2 

and  7/4  €r  F3  .  Define  773  f—  (34  ®  q2  +  34).  Note  that  773 
will  not  travel,  as  P  can  derive  it. 

•  Generate  circuit  queries:  Take  775  <—  71  +  qi .  Take  qs  t— 
72  +  <74. 

•  Issue  queries.  Send  (771,34,34,775,776)  to  oracle  77,  getting 
back  77(31 ),  77(32),  77(33),  77(34),  77 (35),  n(q6). 

•  Quadratic  correction  test:  Check  that  77(31)  •  77(32)  = 
77(33)  —  77(34).  If  not,  reject. 

•  Circuit  test:  Check  that  (77(35)  —  77(31))  + 

(77(776)  —  77(774))  =  —70.  If  so,  accept . 

Figure  14 — ginger's  PCP  protocol,  which  refines  pepper’s 
protocol  (Figure  13).  This  protocol  eliminates  linearity  testing 
and  repetition,  and  recycles  queries  [9]. 

(see  [30],  definitions  5.2.2,  5.2.8  and  Exercise  17)  im¬ 
plies  that  for  all  PPT  A  (A  can  be  non-uniform), 

Pr  { A(pk ,  Enc  (pk,  r),  r  +  Z\q,  r  +  Z2q)  =  Z\j 

Gen,Enc,r.Zi,Z2 

<l/|F|+es.  (1) 

This  holds  for  all  q  e  F".5 

Now,  assume  to  the  contrary  that  Com¬ 
mit+Multidecommit  does  not  meet  the  definition  of 
(y  -linearity.  Then  there  exists  an  environment  £  produc¬ 
ing  737  qj,  i,j,  k,  Q ,  Q ,  S*  (where  Q  has  qt ,  qj  in  the  zth  and 
yth  positions  and  Q  has  77;  +  qj  in  the  kth  position)  such 
that  Pran  3phases{S*  wins  linearity  under  F}  >  l/|F|+ej. 
Let  q'  =qk  =  q(  +  qr 

We  now  describe  an  algorithm  A  that,  when  given 
input  I  =  (pk ,  Enc (pk,  r),  r  +  Z\cf ,  r  +  Z2q'),  can  re¬ 
cover  Z\  with  probability  more  than  1/|F|  +  es .  A  has 
Q,  Q.  qj ,  7 ij,  i,j,  k  hard-wired  (because  it  is  working  under 
environment  £)  and  works  as  follows: 

(a)  A  gives  (pk ,  Enc(pk,  r))  to  S*  and  ignores  the  reply. 

(b)  A  randomly  generates  a\, ...,  a  ^  and  sends  to  S* 

the  input  (Q,  r+a\q\  4 - h(a,+Zi)^,-| - h(o,'+ 

Z\)qj  +  -  ■  ■+a^lqll).  Zl  is  able  to  construct  this  input 
because  A  was  given  r  +  Z\q'  =  r  +  Z\qj  +  Z\qj.  In 
response,  S*  returns  (b,  a\, . . . ,  a,-, . . . ,  aj, . . . ,  aM). 

(c)  A  randomly  generates  &i, . . . ,  07.  A  sends  to  S*  the 

input  (Q,r  +  a\qi  H - srZ2qk- \ - L  7t;i^;i).  A  is 

able  to  construct  this  input  because  A  was  given  r  + 
Z2q'  =  r+Zoqit .  A  gets  back  (b,  a\, . . . ,  ak, . . . ,  dM). 

At  this  point,  A  assumes  that  the  responses  from  S* 
pass  the  decommitment  phase;  that  is,  A  acts  as  if  b  = 
s+aqfli-|-’  •  •  +  (ct(-+Zi ) a •  •  +  (otj  +Zi )aj + •  •  '+07737 
and  b  =  s  +  cLdi  +  •  •  •  +Z2ak  +  •  •  •  +  a A  can  write 

3We  are  being  loose  here.  Under  the  actual  definition  of  semantic  secu¬ 
rity,  (a)  es  should  be  replaced  with  a  negligible  function  of  n.  and  (b) 
the  claim  holds  only  for  n  sufficiently  large. 
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Ki  =  Z2dk  -  Z\  ( m  +  aj ),  (2) 

where  A  can  derive  K\  =  b  —  b  —  ®  A  +  aiaL. 

Now,  let  t  —  r  +  Z\tf  and  let  t  =  r  +  Z2q'  (both  of 
these  were  supplied  as  input  to  A).  These  two  equations 
concern  vectors.  However,  by  choosing  an  index  i  in  the 
vector  q'  where  q'  is  not  zero  (if  the  vector  is  zero  every¬ 
where,  then  r  is  revealed),  A  can  derive 

K2  =Z2—Z\,  (3) 


a j  =f,(qi)  for  all  i  G  [//.],  where  (qx, . . .  ,q^)  are  the  de¬ 
commitment  queries  generated  by  £,  and  the  probability 
is  over  the  random  inputs  of  S*  and  R  in  both  phases. 

Lemma  A.3.  Let  £3  =  (2  £/9/2  +  1 )  •  ■  Label  the  ;th 

query  in  Q  as  q,  and  the  ;th  response  as  a,.  For  all  Q,  i, 
we  have  Prcomm>decomm{£  f  { @i  f  fv (.q i )  1 }  ^  263. 

Proof.  Follows  from  a  claim  in  [45]  (Claim  B.4).  □ 

Lemma  A.4.  For  all  quq2  G  F",  Prcomm{fv(qx)  + 
fv{qi)  t^/v^i  +  ^2)}  <eF  =  eL  +  6e3. 


where  K2  =  (fW  —  fW) / q'^ . 

Now,  observe  that  if  ak  ^  a,  +  a,  (as  happens  when 
S*  wins),  then  A  can  recover  Z\  by  solving  equations  (2) 
and  (3).  Thus, 

Pr  JA{I)=ZX] 

Gen,Enc,r,Zi  ,Z2,a,d 

>  Pr  {S*  wins  linearity  under  £} 

Gen,Enc,r,Zi  ,Z2,a,a 

=  Pr  { S'  wins  linearity  under  £  \ 

all  3  phases 

>l/|F|+es.  (4) 

The  equality  holds  because  the  distribution 
of  (ax,...,cxi  +  Z\,...,a.j  +  Zi,...,aM)  and 
(&i, . . . ,  Z2, . . . ,  dM)  is  equivalent  to  the  distribu¬ 
tion  from  which  R  selects  in  the  decommit  phases  of  the 
three-phase  experiment,  under  Commit+Multidecommit. 
Meanwhile,  inequality  (4)  contradicts  inequality  (1).  □ 

The  lemmas  ahead  show  that,  under  Com¬ 
mit+Multidecommit,  S  is  bound  to  a  nearly  linear 
function, /(•);  specifically, /(•)  is  J*-close  to  linear  for 
small  S*.  By  contrast,  previous  work  [35,  45]  showed 
only  that  S  was  bound  to  some  function /(•). 

We  now  give  some  notation  and  restate  two  claims 
from  [45].  Let  £  be  the  event  that  R's  output  is  a  vec¬ 
tor  (ai, . . . ,  aM);  equivalently,  £  is  the  event  that  R's  out¬ 
put  is  non-_L.  Below,  we  sometimes  write  Prcomm{-}  or 
Pi'decomm{-}  to  mean  the  probability  over  the  random 
choices  of  the  commit  or  decommit  phases. 

Lemma  A.2  (Existence  of  an  extractor  function  [45]). 

Let  (5,  R)  be  a  CFMD  protocol  with  binding  error  ch-  Let 
ec  =  ft  •  2  •  (2-£/9/2  +  1)  •  f/es-  Let  v  =  (vs*,vR)  rep¬ 
resent  the  views  of  S*  and  R  after  the  commit  phase  (v 
captures  the  randomness  of  the  commit  phase).  For  ev¬ 
ery  efficient  S*  and  for  every  v,  there  exists  a  function 
/,,  :  F"  — >  F  such  that  the  following  holds.6  For  any  en¬ 
vironment  £,  the  output  of  R  at  the  end  of  the  decommit 
phase  is,  except  with  probability  ec,  either  _L  or  satisfies 

6Note  that  after  the  commit  phase, /v(-)  is  deterministic,  (fv(-)  is  de¬ 
fined  [35, 45]  to  map  q  to  the  value  that  R  is  most  likely  to  successfully 
output  in  the  decommit  phase.) 


Proof.  Assume  otherwise.  Then  for  some  qx  and  q2,  we 
have  PrCOmm{fv{qi)  +fv(qi)  ff  {qi  +^2)}  >  er,  which 
implies  Pr-dii3Ph^es{fv{q\)  +f\qi)  ¥=fv(qi  +<72)}  >  f-F, 
since  we  can  “add  coin  flips  that  don’t  matter”,  namely 
those  of  the  two  decommit  phases. 

Now,  consider  the  game  in  the  definition  of  e/,- 
linearity,  and  set  Q  =  (qx.q2,...)  and  Q  =  (qx  + 
q2,  ■  ■  ■)■  Let  77  be  the  event  that  S*  wins  in  this  game. 
Let  v  be  the  event  that  the  outputs  01,02,01  are  given 
by  the  function /„(•).  Then  Prall3phases{ni/}  <  6e3,  by 
Lemma  A. 3,  by  the  union  bound,  and  by  (again)  “adding 
coin  flips  that  don’t  matter”  to  get  from  a  probability 
over  two  phases  to  one  over  three  phases.  Now,  note  that 
Frail  3  phases {v \ v}  >  €f,  by  the  contrary  hypothesis.  This 
implies  that  Pi'ai^phaseslfy}  >  eF  —  6e2  =  eL ,  which  con¬ 
tradicts  the  definition  of  e^-linearity.  □ 


Lemma  A. 4  almost  talks  about  a  linearity  test  [16]! 
But  linearity  testing  theory  [8]  relates  (a)  the  probabil¬ 
ity  over  randomly  chosen  queries  that  the  test  fails  and 
(b)  the  closeness-to-linearity  of  the  tested  function.  Thus, 
to  apply  the  theory,  we  line  up  Lemma  A. 4  and  (a). 

Lemma  A.5.  With  probability  greater  than  1  —  ^/eF  over 
the  commit  phase,  the  fraction  of  (qx,  q2)  pairs  that  cause 
/,,(•)  to  fail  the  linearity  test  is  <  yfef. 

Proof.  Let  Iv,qi,q2  be  an  indicator  random  variable  that 
equals  1  if,  in  view  v  (that  is,  given  the  randomness  of 
the  commit  phase),  fv(qx  +  q2)  fv(qx)  +fv(q2).  The 
lemma  is  equivalent  to  the  statement 


Pr  {  Pr  {Iv,quq2  =  1}  >  a/ef}  <  V^f- 

comm  qi,q2 


Now,  define  a  random  variable  Yv  =  ^  q2  /v,?l,92, 
where  Q  =  |F|"  is  the  number  of  possibilities  for  each 
of  qx  and  q2.  By  linearity  of  expectation,  £Comm[Fv]  = 
^2  •  (£ [/,,.! ]  +  •  •  •  -\-E[1vq 2]),  where  E[/Vf  is  the  probabil¬ 
ity,  over  the  commit  phase,  that  a  particular  (qj,  qk )  pair 
causes /,,(•)  to  fail  the  linearity  test.  Lemma  A. 4  implies 
that  E[Ivj\  <  eF  for  all  i;  hence,  £COmm[Fv]  <  £f-  We  now 
apply  a  Markov  bound  to  Yv: 


Pr  {Yv  >  a/ef}  < 


i[*V 
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But  Yv  is  equivalent  to  Pr9l  ,q2{Iv,qi,q2  =  making  this 
substitution  immediately  above  yields  the  lemma.  □ 

Lemma  A.6.  Let  <5*  be  the  lesser  root  of  6 S2  -  35  + 
yjef  =  0.  If  s/cp  <  |,  then  with  probability  greater  than 
1  —  y ftp  over  the  commit  phase, /,,(•)  is  <5*-close  to  linear. 

Proof.  We  use  the  linearity  testing  results  of  Bellare  et 
al.  [8,  9]  and  the  terminology  of  [8].  Define  Dist(/\ g) 
to  be  the  fraction  of  inputs  on  which  /  and  g  disagree. 
Define  Dist(/)  to  be  the  fraction  of  inputs  on  which 
/  disagrees  with  its  “closest  linear  function”  [8].  De¬ 
fine  Rej  ( / )  to  be  the  probability,  over  uniformly  random 
choices  of  x  and  y  from  the  domain  of/,  that/(x)  +f(y)  f1 
f(x  +  y)\  Rej(/)  is  the  probability  that/  fails  the  linearity 
test.  As  stated  by  Bellare  et  al.  [8]: 

•  If  Dist (f)  =  <5,  then  Rej (f)  >35  —  652. 

•  If  Distf/)  >  then  Rej (/)  >  |. 

The  above  implies  the  following  claim:  for  all  5'  £ 
{/  |  3 5'  -  6 5'2  <  |  and  0  <  S'  <  ±},  if  Re\(f)  <  3 5'  - 
6 5'2,  then  Dist(/)  <  5' .  (To  see  this,  fix  5' .  Assume  to  the 
contrary  that  <5  =  Dist(/)  >  S' .  There  are  two  cases,  and 
both  contradict  the  given.  If  5  <  l  then  Rej(/)  >3 5  — 
6  S2  >  36' -65'2.  If  6  >  i,  then  Rej  (f)  >  \  >  35' -65'2.) 

From  lemma  A. 5,  the  probability  is  greater  than  1  — 
y/e/  over  the  commit  phase  that  Rej(/V,)  <  v /i/.  We  call 
such  commit  phases  usual.  Under  a  usual  commit  phase, 
we  can  apply  the  claim  just  above.  To  do  so,  we  assume 
that  yjtf  <  and  we  set  (5*  so  that  yjef  =  35*  —  6<5*2 
and  (such  a  5*  is  guaranteed  to  exist  because  the 

parabola  is  symmetric  about  5  =  \).  The  claim  implies 
that  Dist(/V)  <  6*,  or  that/,,  is  (5*-close  to  linear.  □ 

Lemma  A.7.  If  the  PCP  oracle  tt  is  known  to  be  5*-close 
to  linear,  then  the  linear  PCP  (Section  A.l)  with  linearity 
testing  removed  has  soundness  error  k  >  max{4(5*  + 
J_  4A*  _l  _Lt 

Proof.  This  follows  from  the  proof  flow  that  establishes 
the  soundness  of  linear  PCPs,  as  in  [5],  (A  self-contained 
example  is  in  Appendix  D  of  [45].)  Those  proofs  first 
establish  that  if  the  linearity  test  passes  with  probabil¬ 
ity  higher  than  the  soundness  error,  then  7 r  is  (5-close  to 
linear,  for  some  5.  However,  if  we  are  given  that  7r  is  en¬ 
close  to  linear,  then  we  can  start  those  proofs  midway 
and  obtain  the  soundness  of  7r  as  n.  □ 

Proof  of  Theorem  A.l.  Lemma  A. 2  implies  that  there 
exists  an  extractor  function  that  determines  a  (possibly 
incorrect)  oracle  7t  such  that,  if  V'  does  not  reject  during 
decommit,  then  with  all  but  probability  ec,  V'  receives 
back  n(qi), . . .  ,Tt{q^).  We  can  thus  “pay”  probability 
ec  in  the  union  bound  (below)  to  assume  that  V'  hears 
back  from  7t  itself.  This  allows  us  to  apply  Lemma  A. 6, 


at  which  point  we  can  “pay”  y/ef  more  probability  (again 
in  the  union  bound  below)  to  get  that  ir  is  5* -close  to  lin¬ 
ear.  (Applying  the  lemma  requires  that  y fef  <  =,  and  we 
will  verify  below  that  this  bound  holds.)  Now,  we  can  ap¬ 
ply  Lemma  A. 7  to  p  runs  of  the  PCP  protocol,  giving  a 
PCP  soundness  error  of  kp.  Thus,  the  probability  that  V' 
wrongly  accepts  a  proof  is  bounded  from  above  by: 

e<j  =  ec  +  \fef  +  kp  ■ 

By  inspection  (of  the  lemmas),  the  dominant  contributor 
to  ec,  namely  y/ef,  is  proportional  to  y/l/|F|.  □ 

We  compute  a  bound  on  ec  as  follows. 

•  ec  is  given  in  Lemma  A. 2.  We  take  p  =  6  (per  Fig¬ 
ure  14).  We  also  take  e^  =  1/|1F|  (following  [45];  this 
amounts  to  ignoring  the  error  from  the  semantic  se¬ 
curity  of  the  homomorphic  encryption  scheme)  and 
|F|  =  2128,  giving  ec  <  7.4  •  10~12. 

•  =  £l  +  6e3  (from  Lemma  A.4).  e^  is  given  in 
Lemma  A. 3.  We  set  e/,  =  1/|F|  (which  again  amounts 
to  ignoring  e^).  Again  taking  |F|  =  2128,  we  get 
y//  <  1.9  •  1CT6.  Thus,  yJTf  <  2/9,  as  required. 

•  k  =  4-5*  +  |f| ,  where  5*  is  the  lesser  root  of  6<52  —  35+ 
y flf.  This  gives  5*  =  6.4  •  10~7  and  k  =  2.6  •  10"6. 

Since  n  and  y Tf  are  roughly  the  same,  there  is  not 
much  point  to  taking  p  >  1 .  Thus,  we  take  p  =  1 ,  giving 
ec  <  4.5  •  10”6  when  |F|  =  2128.  When  |F|  =  2192,  we 
get  eG  <  2.8  •  10"9. 

A.3  Optimizing  out  queries 

ginger’s  PCP  protocol  includes  two  further  refine¬ 
ments.  First,  the  protocol  reuses  <74  and  <71  from  test  to 
test.  This  reuse  is  sound  because  the  PCP  soundness 
lemma  [5]  is  of  the  form,  “if  all  tests  pass  with  proba¬ 
bility  greater  than  X,  then  the  proof  oracle  7r  has  a  cer¬ 
tain  desired  property”;  meanwhile,  as  Bellare  et  al.  [9] 
observe,  the  tests  need  not  be  independent!  One  can  ob¬ 
serve  the  savings  by  comparing  Figure  13  (minus  the  lin¬ 
earity  queries)  to  Figure  14.  The  protocol  goes  from  8 
queries  (the  original  14  minus  6  linearity  queries)  to  6 
queries,  though  the  real  savings  for  the  prover  is  in  re¬ 
ducing  the  4  high-order  queries  (that  is,  queries  to  the 
Fs  component  of  7r)  to  3.  Moreover,  the  verifier  saves 
because  it  goes  from  generating  pseudorandomness  for  3 
high-order  queries  (including  72)  to  2.  Second,  V  avoids 
transmitting  a  query  (q^)  that  P  can  generate  for  itself. 
This  optimization  offsets  the  consistency  query,  which  is 
computed  over  Z  not  Z/p  (owing  to  the  details  of  our 
use  of  ElGamal  [45,  Appendix  E])  and  thus  has  roughly 
twice  as  many  bits  as  a  PCP  query. 
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B  Signed  integers,  floating-point  rationals 

In  this  appendix  and  the  two  ahead,  we  describe  how 
GINGER  applies  to  general-purpose  computations.  This 
appendix  describes  ginger’s  representation  of  signed 
integers  and  its  representation  of  primitive  floating-point 
quantities  (this  treatment  expands  on  Section  4.1).  The 
next  appendix  details  the  case  study  (from  Section  4.2)  of 
an  inequality  test  and  a  conditional  branch.  Appendix  D 
describes  other  program  constructs. 

Our  goal  in  these  appendices  is  to  show  how  to  map 
computations  to  equivalent  constraints  over  finite  fields 
(according  to  the  definition  of  equivalent  given  in  Sec¬ 
tion  2.1).  To  do  so,  we  follow  the  framework  from  Sec¬ 
tion  4.  Recall  that  the  three  steps  in  that  framework  are: 
(Cl)  Bound  the  computation  4/,  which  starts  out  over 
some  domain  D  (such  as  Z  or  Q),  to  ensure  that  T  stays 
within  some  set  U  C  D;  (C2)  Establish  a  map  between  U 
and  a  finite  field  F  such  that  computing  T  in  F  is  equiva¬ 
lent  to  computing  T  in  U.  (C3)  Transform  the  finite  field 
version  of  the  computation  into  constraints. 

B.l  Signed  integers 

To  illustrate  step  Cl,  consider  m  x  m  matrix  multiplica¬ 
tion  over  signed  integers,  with  inputs  of  N  bits  (where 
the  top  bit  is  the  sign):  the  computation  does  not  “leave” 
U  =  [ — m  ■  2 2N-\m  •  22a'-1),  where  U  C  Z. 

For  step  C2,  we  take  F  =  Z /p  and  define  9  between  U 
and  TL/p  as  follows: 


B.2  Floating-point  rational  numbers 

Step  Cl 

To  illustrate  this  step,  we  again  consider  m  x  m  ma¬ 
trix  multiplication  and  this  time  require  the  input  en¬ 
tries  to  be  in  the  set  T  =  {a/b  :  \a\  <  2 Na,b  G 
{1,2, 22, 23, . . .  ,2Nb}}.  To  bound  the  computation  to  a 
set  U ,  we  use  the  claim  below. 

Claim  B.l.  For  the  computation  of  matrix  multiplica¬ 
tion,  with  input  entries  restricted  to  T ,  the  computation 
of  matrix  multiplication  is  restricted  to  U  =  {a/b:  \a\  < 
2N'«,b  G  {1, 2, 22, 23, . . . ,  21Nh{{.  for  N'a  =  2 Na  +  2 Nb  + 
log2  m. 

Proof.  Consider  an  entry  in  the  output;  it  is  of  the  form 
ELi  AikBkj,  where  each  A^B/g  is  contained  in  S  = 
{a/b:  \a\  <2 2N\b  G  {1, 2, 22, 23, . . . , 21N»}}.  Thus,  we 
can  write  each  output  entry  as  El-Li  ak/bk.  the  sum  of 
m  numbers  from  the  set  S.  Writing  each  b^  as  2et,  and 
letting  e*  =  maxj  ek,  we  can  write  the  sum  as 

E  k^~tk 

2e" 

The  denominator  of  this  sum  is  contained  in 
{1, 2, 22, 23, . . . ,  22Nb}.  The  absolute  value  of  each  sum¬ 
mand  in  the  numerator,  a  if.''  ~ek,  is  no  larger  than 
22Na+2Nb,  an(j  thej-g  are  m  summands,  so  the  absolute 
value  of  the  numerator  is  no  larger  than  m  ■  22Na+2Nb  = 
22N„+2Nb+\og2m  f0j-t j or j  3  the  intermediate  sums  are 

contained  in  U  (they  have  fewer  than  m  terms).  □ 


9:  U  — ¥  Jj/p 
u  i — y  u  mod  p. 


Note  that: 

(1)  If  U  is  an  interval  [a,b\  and  |Z/p|  >  |t/|,  then  9  is 
1-to-l. 

(2)  Ifxi,X2  €  U  and  X\  +X2  G  U.  then  9{x i)  +  9{x2)  = 
9{x  i  +  x2). 

(3)  If  x\,x2  G  U  and  x\x2  G  U.  then  9{x\)9{x2)  = 
9{xix2). 

To  argue  property  (1),  take  x  mod  p  =  y  mod  p,  which 
means  x  =  y  +  p  ■  k,  for  k  G  Z.  If  x  y  (so  9  is  not 
1-to-l),  then  | y  —  x\  >  p,  which  implies  that  there  must 
be  at  least  p+  1  elements  in  U,  since  U  is  an  interval  that 
includes  x  and  y.  But  \U\  <  |Z/p|  =  p.  a  contradiction. 
Properties  (2)  and  (3)  follow  because  9  is  a  restriction 
of  the  usual  reduction  map,  so  it  preserves  addition  and 
multiplication. 

Thus,  computation  in  7L/p  is  isomorphic  to  computa¬ 
tion  in  U:  the  constraint  representation  uses  only  field 
operations  to  represent  computations  (see  Section  2.1), 
and  for  the  purposes  of  field  operations,  Z /p  acts  like  U. 


Step  C2 

We  must  identify  a  field  F  where  the  computation  can  be 
mapped;  that  is,  we  need  a  field  that  behaves  something 
like  Q.  For  this  purpose,  we  take  F  =  Frac(Z/p),  the 
quotient  field  of  Z /p,  which  we  denote  Q /p. 

This  paragraph  reviews  the  definition  and  properties  of 
Q/p  because  we  will  need  these  details  later.  As  a  quo¬ 
tient  field,  Q/p  is  the  set  of  equivalence  classes  on  the 
setZ/p  x  (Z/p\  {0}),  under  the  equivalence  relation  ~, 
where  {a,  b)  ~  (c,  d)  if  ad  =  be  mod  p;  the  field  oper¬ 
ations  are  {a,  b )  +  (c,  d)  =  ( ad  +  be  mod  p,  bd  mod  p) 
and  (a,  b)  ■  (c,  d)  =  ( ac  mod  p,  bd  mod  p),  where  a  pair 
(x,y)  represents  its  equivalence  class.  Note  that  although 
elements  of  Q/p  are  represented  as  having  two  compo¬ 
nents,  each  of  which  seems  able  to  take  p  or  p  —  1  values, 
the  cardinality  of  Q/p  is  only  p.  In  fact,  Q/p  is  isomor¬ 
phic  to  Z /p,  via  the  map /((a,  b))  =  a  ■  b~l . 

We  must  now  define  a  map  from  U  to  Q/p;  in  doing 
so,  we  will  take  U  to  be  an  arbitrary  subset  of  Q: 


9:  U 
a 
b 


Q/p 

( a  mod  p,  b  mod  p). 


17 


Note  that  9  is  well-defined.  (This  fact  is  standard,  but 
for  completeness,  we  briefly  argue  it.  Take  q\  = 
q2  =  Then  9(q\)  =  (a\  modp,Z?i  mod p)  and 
9(q2)  =  (ci\X  mod  p .  b\X  mod  p).  But  we  have  (cq  mod 
p){b\x  mod p)  =  (b\  mod p)(a\x  mod  p)  (mod  p),  so 
%i)  ~  d{q2).) 

As  mentioned  above,  Q /p  does  not  have  as  much 
“room”  as  one  might  guess.  To  make  6  1-to-l,  we  must 
choose  p  carefully.  The  lemma  below  says  how  to  do  so, 
but  we  need  a  definition  first.  Define  the  s-value  of  an  el¬ 
ement  q  £  Q  as  follows.  Write  q  as  a/b,  where  a.b  £  Z, 
b  >  0,  and  a  and  b  are  co-prime.  Then  the  s-value  of  q, 
written  s(q),  is  s(q)  =  |a|  +  b.  We  write  the  s-value  of  a 
set  U  C  Q  as  s(U),  and  we  define  it  as  the  largest  s-value 
of  f/’s  elements:  s(U)  =  maxue[/  s(u). 

Lemma  B.2.  For  any  U  C  Q,  if  p  >  s(U)2.  then  9  is 
1-to-l. 

Proof  Take  q\,q2  £  U,  where  9(q\)  ~  d(q2).  We  need 
to  show  that  q\  =  q2.  Write  qi  =  a\/b\  and  q2  =  a2/b2 
in  reduced  form  (that  is,  a,  and  /?,■  are  co-prime).  Note  that 
by  definition  of  s-value  and  choice  of  p,  p  is  greater  than 
each  of  a\,b\,a2,b2,  so  we  can  write  9(q\)  as  (a\,bi) 
and  9(q2)  as  (a2,b2).  Since  9(q i)  ~  b(q2),  we  have 
a\b2  =  a2b\  (mod  p).  But  then  if  a\b2  ^  a2b\  (as 
would  be  implied  by  q\  q2)  we  would  have: 

P  <  \o\b2  —  a2b\  j 

<  \a\b2\  +  \a2b\\ 

<  \a\b2\  +  \a2b\  \  +  \a\a2\  +  \b\b2\ 

=  (|«i  |  +  \b\  |)  (|rt2 1  +  \b2\) 

<  s(U)-s(U), 

making  p  <  s(U)2,  a  contradiction.  □ 

Representing  computations  over  Q/ p  faithfully.  Note 
that: 

(1)  If  q\,q2  €  U  and  qi  +  q2  £  U,  then  Q(q\)  +  0(q2)  ~ 
8{q  i  +qi)- 

(2)  If  qi,q2  £  U  and  q\q2  £  U,  then  9(q\)0{q2)  ~ 

0(q\q2)- 

These  properties  can  be  verified  by  inspection.  Since 
9  preserves  addition  and  multiplication,  and  since  9  is 
1-to-l  by  choice  of p,  the  computation  in  Q/p  is  isomor¬ 
phic  to  the  computation  in  Q. 

Examples.  If  U  is  defined  as  in  Claim  B.l,  then  the 
s-value  is  upper-bounded  by 

m  .  22(Na+Nb)  +  22 Nb  <  m  .  22(Na+Nb)  +  22{Na+Nb)  _ 

Applying  Lemma  B. 2,  if  we  take  p  >  (m- \-\)2  ■2A('Na+Nb\ 
then  computation  over  Q/p  is  isomorphic  to  computa¬ 
tion  over  U,  as  claimed  in  Section  4.1.  As  another  ex¬ 
ample,  consider  numbers  of  the  form  a  ■  2~q ,  where 


\a\  <  2N°  and  \q\  <  Nq.  Then  the  prime  requires  at  least 
2  log2(2A,°-|-2A^)  <  2-(max{Afl,  A9}  +  1)  bits,  as  claimed 
in  Section  4.1. 

Canonical  forms  and  9~l 

Later,  it  will  be  convenient  to  have  defined  ()~ 1 
explicitly — and  to  have  expressed  this  definition  in  terms 
of  a  particular  representation  of  elements  of  Q/p.  This 
may  seem  strange  because  the  whole  concept  of  equiva¬ 
lence  class  is  that,  within  a  class,  all  representations  are 
equivalent.  However,  our  constraints  for  certain  compu¬ 
tations,  such  as  less-than,  will  require  assumptions  about 
the  representation  of  an  element  (see  Appendix  C.2). 
Thus,  we  define  a  canonical  representation  below;  we 
focus  on  the  case  when  U  is  of  the  form  {a/b:  |a|  < 
2Na ,  b  £  {1,2, 22,23, . . .  ,2^}}. 

Definition  B.l  (Canonical  form  in  Q/p).  An  element 

(a,  b)  £  9{U)  is  a  canonical  form  or  canonical  represen¬ 
tation  of  its  equivalence  class  if  a  £  [0,  2Na]  U  [p  —  2Na,p) 
and  b  £  {1.2,4,...,  2^ } .  Every  element  in  9(U)  has 
such  a  representation,  by  definition  of  U  and  9. 

We  now  define  (9”1;  let  (ea.  e;,)  denote  a  canonical  form 
of  e: 

9~l:  9{U)  U 

ea/eb.  0  <  ea  <  2N« 

(■ ea-p)/eb ,  p  —  2Na  <  ea  <  p 

Note  that  when  ea  is  in  the  “upper”  part  of  the  range, 
9~l  maps  e  to  a  negative  number  in  Q.  Note  also  that 
the  canonical  form  for  an  equivalence  class  may  not  be 
unique.  However,  the  following  two  claims  establish  that 
this  non-uniqueness  is  not  an  issue  in  our  context. 

Claim  B.3.  9~1  is  well-defined. 

Proof.  For  e  £  9(U).  let  e  =  ( a,b )  ~  ( c,d ),  where 
(a,  b)  and  (c,  d)  are  both  canonical  forms.  We  wish  to 
show  that  9~l((a,  b ))  =  9~l{(c,  d)). 

We  have  9~l((a,b))  £  U  and  9~l{{c,d))  £  U.  by 
definition  of  0-1  and  U.  Also,  we  have  6*(0_1((a,  b)))  ~ 
( a.b ),  as  follows.  If  a  £  [0, 2Na\,  then  9~l((a,b))  = 
a/b  and  9{a/b)  =  (a.b).  If  a  £  \p  —  2 N“,p),  then 
9~l((a,b))  =  (a  —  p)/b  and  9((a  —  p)/b)  =  (a  — 
pmodp.b)  ~  (a.b).  Likewise,  0(0~l((c,d)))  ~  (c.d). 
Now,  let  u\  =  9~l((a,b))  and  u2  =  9~l ((c.d)).  As¬ 
sume  toward  a  contradiction  that  u\  u2:  then  9(u\)  f 
9(u2),  by  Lemma  B.2.  Thus  (a.b)  ~  9(9~l  ((a,  b))  f 
9(9~1((c,  d)))  ~  (c,  d),  a  contradiction.  □ 

Claim  B.4.  An  element  in  9(U)  cannot  have  two  canon¬ 
ical  representations  (a.  b)  and  (c.  d)  with  a  £  [0, 2Na]  and 
c£  \jr-2N“,p). 
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Proof.  Take  ( a ,  b)  ~  (c,  d)  where  a  £  [0, 2Na ]  and  c  £ 
\p  —  2 N“,p)  (note  that  b,d  >  0).  Because  0~l  is  a  func¬ 
tion  (Claim  B.3),  9~l((a,  b))  =  9~l((c,  d)).  However, 
9~l((a,b))  =  a/b  >  0  and  9~l((c,d))  =  ( c—p)/d  <  0, 
which  is  a  contradiction.  □ 

Discussion 


C  Case  study:  branch  and  inequalities 

Below,  we  will  give  constraints  for  a  computation  that 
branches  based  on  a  less-than  test.  (This  will  instantiate 
step  C3  for  the  case  study  in  Section  4.2.)  Most  of  the 
work  is  in  representing  the  less-than  test;  we  do  so  with 
range  constraints  that  take  apart  a  number  and  interro¬ 
gate  its  bits. 


Most  of  our  work  above  presumed  a  restriction  on  U: 
that  the  denominators  of  its  elements  are  powers  of  2. 
We  defined  U  this  way  because,  without  this  restriction, 
we  would  need  a  much  larger  prime  p,  per  Lemma  B.2. 
However,  this  restriction  is  not  fundamental,  and  our 
framework  does  not  require  it.  On  the  other  hand,  the 
restriction  yields  primitive  floating-point  numbers  with 
acceptable  precision  at  acceptable  cost  (see  Section  4.1). 

Implementation  detail 

When  working  with  computations  over  Q,  we  express 
them  over  the  finite  field  Q/p.  However,  our  implemen¬ 
tation  (source  code,  etc.)  assumes  that  the  finite  field  is 
represented  as  'Lip.  Fortunately,  as  noted  above,  Q /p  is 
isomorphic  to  L/p  via  the  following  map: 

/:  Q Ip  ->•  L/p 
(a,b)  i  ^  ab~x . 

We  take  advantage  of  this  isomorphism  to  reuse  our  im¬ 
plementation  over  L/p.  Specifically,  when  computing 
over  Q/p,  V  and  P  follow  the  protocol  below. 

Definition  B.2  (GINGER-Q  protocol).  Let  T  he  a  com¬ 
putation  over  Q/p,  and  let  T'  be  the  same  computation, 
expressed  over  L/p.  The  GINGER-Q  protocol  for  verify¬ 
ing  >|/  is  defined  as  follows: 

1.  V  — >  P:  a  vector  x,  over  the  domain  Q/p. 

2.  P  —y  V:y  =  T'(x). 

3.  P  — >  V:  x'  and  /.  P  obtains  x1  ,y'  (which  are  vectors 
in  L/p)  by  applying  /  elementwise  to  x  and  y. 

4.  V  checks  that  for  all  (a,  b )  £  {x  U  y}  and  the  corre¬ 
sponding  element  c  £  {x!  LJ  y' } ,  cb  =  a  mod  p.  This 
confirms  that  P  has  applied  /  correctly.  If  the  check 
fails,  V  rejects. 

5.  V  engages  P  using  the  existing  GINGER  implemen¬ 
tation,  to  verify  that  /  =  'T//). 


C.l  Order  comparisons  over  the  integers 

Preliminaries 


We  will  assume  that  the  programmer  or  compiler  has  ap¬ 
plied  steps  Cl  and  C2  to  bound  the  inputs,  x\  and  x2, 
and  to  choose  F;  thus,  their  difference  is  bounded  too. 
Specifically,  we  assume  X\  —  X2  £  U  C  [— 2N~l,  2W_1), 
F  =  L/p  for  some/?  >  2N ,  and  9{x)  =  x  mod/?.  (See 
Appendix  B.l.) 

With  these  restrictions,  x\  <  x2  if  and  only  if  x\  —  x2£ 
[— 2W_1,0),  which  holds  if  and  only  if  9(x i)  —  9(x2)  £ 
[/?  —  2 N~1,p);  the  second  equivalence  follows  because 
9  is  1-to-l  and  preserves  addition  and  multiplication,  as 
shown  in  the  previous  appendix. 


Step  C3 

To  instantiate  step  C3,  we  write  a  set  of  constraints,  C<:7 


B0(l  -B0)  =0, 
Bj(2-Bj)  =0, 


C<={ 


BN_2{2N~2-BN_2)=0, 


> 


{  9{X1)  -  9(X2)  -{p-  2N~l)  -  £f=o: 2B,  =  0  J 


Lemma  C.l.  C<  is  satisfiable  if  and  only  if  0(x\ )  — 
9{x2)  £\p-  2 N~\p). 

Proof.  Assume  9(x i)  —  9(x 2)  £  \p  —  2 /“',/?).  Let  A3  = 
9(xi)  —  9(x2)  —  (/?  —  2n~i).  Observe  that  A3  £  [0,2W_1), 
so  A3?s  binary  representation  has  bits  zo,Zi,  ■  ■  ■  ,Zn-2- 
Now,  set  B,  =  n  ■  2'  for  i  £  {0,1, . . .  ,N  —  2}.  This  will 
satisfy  all  but  the  last  constraint  because  B ,  is  set  equal 
to  either  0  or  2'.  And  the  last  constraint  is  satisfied  from 
the  definition  of  A3  and  because  we  set  the  {B,}  so  that 
///( ~  Bj  =  A3.  For  the  other  direction,  if  the  constraints 

are  satisfiable,  then  9{xi)  —  9{x2)  =  p  —  2N~l  +Y/!i=Q  Bu 
where  the  {B,}  are  powers  of  2,  or  0.  This  means  that 
6>(xi)  -  9(x2)  £  fp-  2N~1,p).  □ 


The  implementation  convenience  carries  a  cost:  P 
must  compute  b~x  for  each  element  a/b  in  the  input  and 
output  of  T  (as  part  of  computing/),  and  V  must  check 
that  P  applied  /  correctly.  On  the  other  hand,  some  cost 
seems  unavoidable.  In  fact,  it  might  cost  even  more  if 
the  implementation  worked  in  Q/p  directly:  arithmetic 
is  roughly  twice  as  expensive  using  the  Q/p  representa¬ 
tion  versus  the  L /p  representation. 


Corollary  C.2.  For  a/  ,  X2  as  restricted  above,  C<  is  satis¬ 
fiable  if  and  only  if  xi  <  x2. 

In  other  words,  assuming  the  input  restrictions,  C<  is 
equivalent  to  the  logical  test  of  <  over  L. 

7Step  C3  in  the  body  text  (§4)  calls  for  "equivalent”  constraints,  but  the 
definition  of  "equivalent”  in  Section  2. 1  presumes  a  designated  output 
variable,  which  the  constraints  for  logical  tests  do  not  have.  However, 
one  can  extend  the  definition  of  "equivalent”  to  logical  tests. 
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C.2  Order  comparisons  over  the  rationals 

When  dealing  with  the  rationals,  extra  preliminary  work 
is  required  to  apply  step  C3;  the  core  reason  is  that  each 
element  in  Q/p  has  multiple  representations  (recall  that 
Q/p  is  isomorphic  to  Z /p). 

Preliminaries 

We  assume  that  the  programmer  or  compiler  has  ap¬ 
plied  steps  Cl  and  C2  to  restrict  the  inputs,  xj  and  x2, 
so  that  xi  —  X2  G  U.  for  U  =  { a/b :  |a|  <  2Na,b  G 
{1,2, 22, ,  2^}}.  Similarly,  we  assume  that  F  is  Q/p , 
p  is  chosen  according  to  Lemma  B.2,  and  9  (a/b)  = 
(a  mod  p,  b  mod  p).  (See  Appendix  B.2.) 

At  this  point,  we  need  the  x\  <  X2  test  to  be  in  a  form 
suitable  for  representation  in  Q/p.  Observe  that  x\  <  X2 
if  and  only  if  X\  —  x2  G  S  =  {a/b:  —  2Na  <  a  < 
0,  b  G  {1,2, 22, . . . ,  2^}},  which  holds  if  and  only  if 
9(x i)  —  9(x 2)  G  9(S)\  as  with  the  integers  case,  the  sec¬ 
ond  biconditional  follows  because  9  is  1-to-l,  and  pre¬ 
serves  addition  and  multiplication.  However,  we  wish  to 
represent  this  condition  in  a  way  that  explicitly  refers  to 
the  representation  of  9(x\)  —  9(x 2). 

Claim  C.3.  9(x  1)  —  0(x2)  G  9(S)  if  and  only  if  the 
numerator  in  the  canonical  representation  (see  Defini¬ 
tion  B.l)  of  9(x  1)  —  9(x 2)  is  contained  in  [p  —  2N\p). 

Proof  We  will  use  the  definition  of  9~l  in  the  previ¬ 
ous  appendix.  Let  e  =  9(x  1)  —  9(x 2).  If  e  G  9(S ), 
then  9~1(e)  =  a/b.  where  a  G  \—2Na,  0)  and  b  G 
{l,2,22, . . .  ,2Nb}.  Thus,  9(a/b)  =  (p  +  a.  b),  where 
p  +  a  G  \p  —  2 Na,p).  and  9(a/b)  =  9(9~l(e))  ~  e,  so  e 
has  a  canonical  representation  of  the  required  form.  On 
the  other  hand,  if  e  ~  (a.  b),  where  a  G  \p  —  2 N“,p),  then 
9~l(e)  =  ( a  —  p)/b  G  S,  so  e  ~  9(0~l(e))  G  9{S).  □ 


Lemma  C.4.  C<  is  satisfiable  if  and  only  if  the  numer¬ 
ator  in  the  canonical  representation  (see  Definition  B.l) 
of  9(x  1)  —  9{x 2)  is  contained  in  \p  —  2 N“,p). 

Proof  Assume  that  A3  =  9{x\)  —  9{xf)  has  the  required 
form  (a.  b).  We  have  k  =  log2  b  G  {0, 1, 2, . . . , N/,}  and 
a  G  \p  —  2 N“,p).  Now,  take  B ).  =  (1,1)  and  all  other 
Bj  =  (0, 1);  this  satisfies  all  of  the  B,  constraints,  includ¬ 
ing  Bi~{l,  1)  =  (0, 1),  which  requires  that  exactly 
one  Bj  be  equal  to  (1, 1 ).  For  B.  take  B  =  (1  ,b)  =  (1,2*), 
to  satisfy  B  -  £f=o fi,  •  (1, 2f)  =  (0, 1). 

Now,  let  a'  =  a  —  (p  —  2Na ) .  The  binary  representation 
of  a'  has  bits  zo,Zi,  ■  ■  -  ,ZNa- 1-  Set  A,-  =  (zit  1)(2',  1)  for 
i  G  {0,1,...,  AC/  —  1 }  -  This  will  satisfy  all  of  the  individ¬ 
ual  Aj  constraints.  And,  since  A,  =  ( a ' ,  1),  we  can 

take  A  =  (a,  1)  to  satisfy  A  —  (p  —  2Na,  1)  —  Y/H/Lq  *-A/  = 
(0,1).  The  remaining  constraint  is  the  last  one  in  the 
list.  It  is  satisfiable  because  we  took  B  =  {\,b)  and 
A  =  ( a ,  1),  giving  A3  —  ( a ,  1)  •  (1,  £>)  =  (0, 1). 

For  the  other  direction,  if  the  constraints  are  satis¬ 
fiable,  then  A3  =  9(x  1)  —  9(x 2)  can  be  written  as 
(a,  1)(1,&),  where  b  G  {1, 2, . . . ,  2Nb}  and  where  a  = 
p  —  2Na  +  z{21,  for  Zi  G  {0, 1}.  This  implies  that 

a€\p-  2Na,p).  □ 

In  analogy  with  the  integers  case,  notice  that  the 
lemma,  together  with  the  reasoning  in  “Preliminaries”, 
implies  the  following  corollary. 

Corollary  C.5.  If  the  input  restrictions  are  met,  then  C< 
is  satisfiable  if  and  only  if  x\  <  x2. 

That  is,  C<  is  equivalent  to  <  over  Q. 

C.3  Branching 


Step  C3 

We  instantiate  step  C3  with  the  following  constraints  C<: 


A0((l,l)— A0) 
A1((2,l)-A1) 

A-Na- i((2A,"_1, 1)  —  Ajva_i) 

A-(P-  2M)-E^‘Af 


C< 


B0((l,l)-*o) 

B,((l,l)-Bi) 


%,((1,1)-Bivj 

,  9{Xf)  -  9{X2)  -  A  ■  B 


=  (0- 1), 

=  (0- 1), 

=  (0- 1), 

=  (0- 1), 

=  (0- 1), 

=  (0,1),  > 

=  (0, 1), 

=  (0- 1), 

=  (0- 1), 

=  (0-1)  , 


We  now  return  to  the  case  study  in  Section  4.2.  We  will 
abstract  the  domain  (Z /p  or  Q/p):  when  we  write  0  in 
constraints  below,  it  denotes  the  additive  identity,  which 
is  (0, 1)  in  Q/p,  and  when  we  write  1,  it  denotes  the 
multiplicative  identity,  which  is  (1, 1)  in  Q/p.  Recall  the 
computation  and  the  constraints  C.\,  (Figure  3): 


if  (XI  <  X2) 

Y  =  3 

else  C-isr  = 

Y  =  4 


M{C<}, 

M(Y  —  3)  =0, 

(1  —  M){C>=}, 

(1  -M)(Y- 4)  =0 


We  now  argue  that  is  equivalent  to  'll  (The  definition 
of  “equivalent”  is  given  in  Section  2.1.) 

Lemma  C.6.  The  constraints  C,|, (  A|  =  x\,  A2  =  x2,  Y  = 
y)  are  satisfiable  if  and  only  if  y  =  \l/(xi,x2). 

Proof.  Assume  C  =  C^(X\  =  x\,  A2  =  x2,  Y  =  y)  is  sat¬ 
isfiable.  Since  C<  and  C>=  cannot  be  simultaneously  sat¬ 
isfiable  (that  would  imply  opposing  logical  conditions). 
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then  M  =  0  or  1  —  M  =  0.  If  1  —  M  =  0,  then  y  =  3, 
since  we  are  given  that  the  constraint  M(Y  —  3)  =  0  is 
satisfiable  when  Y  =y.  Moreover,  C<  must  be  satisfiable, 
implying  that  X\  <  X2  (see  Corollaries  C.2  and  C.5).  On 
the  other  hand,  by  analogous  reasoning,  if  M  =  0,  then 
y  =  4,  C>=  is  satisfiable,  and  X\  >  X2-  Thus,  we  have 
two  cases:  (1)  x\  <  xi  and  y  =  3  or  (2)  x\  >  xi  and 
y  =  4.  But  this  means  that  y  =  \&(xi, X2)  for  all  x\ , X2  in 
the  permitted  input. 

Now  assume  thaty  =  >L(xi,X2).  MAy  <  xi,  then  y  =  3. 
Take  M  =  1  to  satisfy  the  constraints  (1  —  M){C>=}  =  0 
and  ( 1  —  M){Y  —  4)  =  0.  Also,  M(Y—  3)  =  0  is  satisfied, 
because  y  =  3.  Last,  C<  can  be  satisfied,  because  x\  <  X2. 
Thus,  the  constraints  are  satisfiable  if  x\  <  xo .  Similar 
reasoning  establishes  that  the  constraints  are  satisfiable 

if  X\  >  X2-  □ 


We  can  generalize  the  computation  T.  For  instance, 
let  T 1 , 4>2  be  sub-computations,  which  we  abbreviate  in 
code  as  compl  and  comp2.  Let  t  and  Cy2  denote  the 
constraints  that  are  equivalent  to  T 1  and  Ti,  and  rename 
the  distinguished  output  variables  in  C^l  and  C$2  to  be 
Y 1  and  L,  respectively.  Below,  T  and  Cy  are  equivalent: 


: 

if  (XI  <  X2) 

Y  =  compl 
else 

Y  =  comp2 


M{C^ 

M(Y-Yi)  =  0, 

(1  —  M){C>=}, 

(1 

(1  -M)(Y-  Y2)  =0, 


> 


The  reasoning  that  establishes  the  equivalence  is  very 
similar  to  the  proof  of  Lemma  C.6.  (The  differences  are 
as  follows.  In  the  forward  direction,  take  M  =  1.  Then, 
since  Y  =  y  and  M(Y  —  Y\)  is  satisfied,  Y\  =  y\  mean¬ 
while,  (^(Ti  =  y,X  1  =  Xi,X2  =  X2)  must  be  satisfied, 
which  implies  y  =  'P|  (x|,X2)  and  hence  y  =  'I'(xi,X2). 
In  the  reverse  direction,  take  x\  <  X2-  Then  we  have 
y  =  T  ;  {x\  5X2).  But  this  implies  that  when  Y \  =  y,  we 
can  satisfy  C^,,  so  set  Y\  =  y.  Furthermore,  set  Y  =  y, 
and  we  thus  satisfy  M(  Y  —  Y\  )  and  hence  all  constraints.) 

We  can  generalize  further.  First,  the  logical  test  in  the 
“if”  can  be  an  arbitrary  test  constructed  from  ==,  !  =,  &&, 

I  I ,  >,  >=,  <,  <=;  in  this  case,  we  must  also  construct  the 
negation  of  the  test  (just  as  we  need  constraints  that  rep¬ 
resent  both  C<  and  C>=).  Second,  we  need  not  capture  the 
result  of  the  conditional  in  T;  we  can  assign  the  result  to 
an  intermediate  variable  Z.  In  that  case,  we  would  replace 
the  constraints  M(Y  —  Ti)  =  0  and  (1  —M)(Y  —  Y2)  =  0 
withM(Z— Ti)  and  (1 —M)(Z  — T2).  respectively,  and  of 
course  we  would  need  other  constraints  that  capture  the 
flow  from  Z  to  the  ultimate  output,  Y. 


D  Program  constructs  and  costs 

This  appendix  describes  further  program  constructs;  as 
with  the  case  study,  the  work  here  corresponds  to  step  C3 
in  our  framework.  However,  in  this  appendix,  we  will  not 
delve  into  as  much  detail  as  in  the  previous  appendices; 
a  more  precise  syntax  and  semantics  is  future  work.  Be¬ 
low,  we  describe  how  we  map  program  constructs  to  con¬ 
straints  and  then  briefly  consider  the  costs  of  doing  so. 

D.l  Program  constructs 

Aside  from  order  comparisons,  the  computations  and 
constraints  below  are  independent  of  the  domain  of  the 
computation;  as  in  Appendix  C.3,  0  and  1  denote  the  ad¬ 
ditive  and  multiplicative  identities  in  the  field  in  question. 

Tests 

==.  Consider  the  fragment  (compl)  ==  (comp2), 
where  compl  and  comp2  are  computations  T 1  and  dL. 
Renaming  the  output  variables  in  T 1  and  T2  to  be  Y \ 
and  Y2,  respectively,  we  can  represent  the  fragment  with 
the  constraint  Yi  —  13  =  0. 

!=.  Consider  the  program  fragment  Z1  !=  Z2.  An 
equivalent  constraint  is  M  ■  (Z\  -  Zi)  1  =0,  where  M 
is  a  new  auxiliary  variable.  This  constraint  is  satisfiable 
if  and  only  if  Z\  —  Z2  has  a  multiplicative  inverse;  that  is, 
it  is  satisfiable  if  and  only  if  Zj  —  Z2  7^  0,  or  Z\  /  Z2. 
As  above,  we  can  represent  (compl)  !=  (comp2);  the 
constraint  would  be  M  ■  (Fi  —  Y2)  —  1  =0. 

<,  <=,  >,  >=.  Appendix  C  described  in  detail  the 
constraints  that  represent  <.  A  similar  approach  ap¬ 
plies  for  the  other  three  order  comparisons.  For  exam¬ 
ple,  for  XI  <=  X2  over  the  rationals,  we  want  to  en¬ 
force  that  the  canonical  numerator  (see  Definition  B.l) 
of  X\  —  X2  £  [p  —  2 Na,p)  U  {0}.  To  do  so,  we  modify 
C<  in  Appendix  C.2  as  follows.  First,  we  add  a  constraint 
A'0(A'0  —  (1, 1))  =  (0, 1).  Second,  we  change  the  A  con¬ 
straint  from 


Na- 1 

A  —  (p  —  2Na,  1)  —  J2Ai  =  (  0,1) 

i= 0 

to 

Na~  1 

A-(p-2\l)-  Y^Ai-K  =  (0,1). 

i=0 

Composing  tests  into  expressions 

To  compose  logical  expressions,  we  provide  &&  and  I  I . 
We  do  not  provide  logical  negation  explicitly,  but  our 
computational  model  includes  inverses  for  all  tests  (for 
example,  ==  and  !  =),  so  the  programmer  or  compiler  can 
use  DeMorgan’s  laws  to  write  the  negation  of  any  logical 
expression  in  terms  of  &&  and  I  I . 

I  |.  Consider  the  expression  (condl)  I  I  (cond2), 
and  let  C\  and  (L  be  the  constraints  that  are  equivalent  to 
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condl  and  cond2  respectively.  The  expression  is  equiv¬ 
alent  to  the  following  constraints,  where  M\ ,  M2  are  new 
variables: 

r  (Af!  -  1)(M2  -  1)  =  0,  ) 

C\ I  =  <  Mi{Ct},  > 

[  J 

We  now  argue  that  C  \  \  is  equivalent  to  the  original  ex¬ 
pression.  If  condl  holds,  then  C \  is  satisfiable;  choose 
M i  =  l  and  M2  =  0  to  satisfy  all  constraints.  Note  that 
if  cond2  also  holds,  then  setting  M2  =  1  also  works,  but 
the  prover  might  wish  to  avoid  “executing”  (i.e.,  finding 
a  satisfying  assignment  for)  C2.  On  the  other  hand,  if  C\  \ 
is  satisfiable,  then  Mi  =  1  or  M2  =  1,  or  both.  If  Mi  =  1, 
then  C 1  is  satisfied,  which  implies  that  condl  holds.  The 
identical  reasoning  applies  if  M2  =  1 . 

&&.  To  express  (condl)  &&  (cond2),  the  program¬ 
mer  simply  includes  C\  and  02- 

Conditionals 

We  covered  conditional  branching  in  detail  in  Ap¬ 
pendix  C.3.  Below  we  describe  two  other  conditional 
constructs,  EQUALS-ZERO  and  NOT-EQUALS-ZERO,  that 
are  useful  as  “type  casts”  from  integers  to  0-1  values. 

NOT-EQUALS-ZERO.  The  computation  T  is 
Y  =  (X  !=  0)  ?  1  :  0,  and  it  can  be  represented 
with  the  following  constraints: 


Cnot-equals-zero 


XM-Y  =  0,  1 
(1  -  F)  -X  =  0  J  ' 


One  can  verify  by  inspection  that  Cnot-equals-zero(F  = 
y,  X  =  x)  is  satisfiable  if  and  only  if  y  =  T'(x).  Note  that 
we  could  implement  NOT-EQUALS-ZERO  by  using  a  con¬ 
ditional  branch  (see  Appendix  C.3)  together  with  a  !  = 
test  (see  above).  However,  relative  to  that  option,  the  con¬ 
straints  above  are  more  concise  (fewer  constraints,  fewer 
variables).  They  are  also  more  concise  than  the  represen¬ 
tation  given  by  Cormode  et  al.  [21].  Roughly  speaking, 
Cormode  et  al.  represent  NOT-EQUALS-ZERO  with  a  con¬ 
straint  like  1  —  Y  =  0,  where  p  is  the  modulus  of 
h/p  (the  approach  works  because  Fermat’s  Little  Theo¬ 
rem  says  that  for  any  non-zero  X,  Xp~x  =  1  (mod  p))\ 
this  approach  requires  log  p  intermediate  variables. 

EQUALS-ZERO.  This  computation  is  the  inverse  of  the 
previous;  the  constraint  representation  of  CEQUAls-zero  is 
the  same  as  Cnot-equals-zero  but  with  F  replaced  by  1  —  F. 


these  constructs — but  must  be  reduced  to  be  degree-2,  as 
required  by  the  protocol  (see  Sections  2. 1-2.2).  Below, 
we  describe  this  reduction  and  its  costs. 

We  will  start  with  the  degree-3  case  and  then 
generalize.  Let  C  be  a  constraint  set  over  variables 
{Z\, . . .  ,Z„,M},  and  let  0  have  a  degree-3  constraint, 

Q{ZU  . . .  ,Z„,M).  Q  has  the  form  R(M)  ■  S(Z, . Z„), 

where  R(M)  is  M  or  (1  — M);  this  follows  because  higher- 
degree  constraints  only  ever  emerge  from  multiplication 
by  an  auxiliary  variable.  We  reduce  Q  by  constructing  a 
C  that  is  the  same  as  C  except  that  Q  is  replaced  with  the 
following  two  constraints,  using  a  new  variable  M'\ 

M'  —  S(Z\, . . .  ,Z„)  =  0, 

R(M)  ■  M'  =  0. 

Claim  D.l.  C  is  satisfiable  if  and  only  if  C  is  satisfiable. 

Proof.  Abbreviate  Z  =  Z\, . . . ,  Z„.  Assume  C  is  satisfied 
by  assignment  Z  =  z,  M  =  m.  Use  this  same  setting  for 
C.  So  far,  all  constraints  other  than  the  two  new  ones 
are  satisfied  in  C' .  To  satisfy  the  two  new  ones,  set  M'  = 
S[z ).  This  satisfies  the  first  new  constraint.  It  also  satisfies 
the  second  new  constraint  because  either  M'  =  0  or  M'  f 
0,  in  which  case  S(z)  7^  0,  which  implies  (because  C  is 
satisfied  and  hence  Q  is  too)  that  Rim)  =  0. 

Now  assume  that  C  is  satisfiable  with  assignment  Z  = 
Z,M  =  m, M'  =  m' .  In  C,  set  Z  =  z.M  =  m.  Now,  in  this 
assignment,  in  C ,  R(m)  =  0  or  m!  =  0.  If  R(m)  =  0, 
then  Q(z,  m)  =  0.  If  m'  =  0,  then  S(z)  =  0,  so  Q(z,  m)  = 
0  again.  □ 

Since  applying  a  single  transformation  of  the  kind 
above  does  not  change  the  satisfiability  of  the  resulting 
set,  we  can  transform  all  of  the  constraints  this  way,  to 
make  M{C}  degree-2.  The  costs  of  doing  so  are  as  fol¬ 
lows.  Each  of  the  \  constraints  in  C  causes  us  to  add 
another  constraint  and  a  new  variable.  Thus,  if  C  has  s 
variables  and  \  constraints,  then  our  representation  of 
M{C}  has  s  +  x  variables  and  2  •  \  constraints. 

The  approach  above  generalizes  to  higher  degrees. 
Higher-degree  constraints  emerge  from  nesting  of 
branches  or  I  I  operations.  If  there  are  k  levels  of  nesting 
somewhere  in  the  computation,  then  the  computation’s 
constraints  have  a  subset  of  the  form 

C„ested=M,{M,_1{---M1{C}---}}. 


D.2  Costs 

As  mentioned  in  Section  4.2,  there  are  two  main  costs  of 
the  constructs  above.  First,  the  order  comparisons  require 
a  variable  and  a  constraint  for  each  bit  position.  Second, 
the  constraints  for  conditional  branching  and  I  I  appear 
to  be  degree-3  or  higher — notice  the  M{C}  notation  in 


(Each  of  the  M,-  could  also  be  1  —  M,.)  Then  there  is  a 
set  of  equivalent  degree-2  constraints  that  uses  in  total 
s  +  k  ■  x  variables  and  {k  +  1)  •  %  constraints. 

The  details  are  as  follows.  Consider  a  single  constraint 
in  Cnestedi  it  has  the  form  R(Mf)  ■  •  ■  R{M2)R{M\  )S{Z)  = 
0,  where  S{Z)  is  degree-2.  Replace  this  constraint  with 
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input : 

Xa:  a  string  of  size  m 

Xb:  two  dimensional  matrix  of  size  m  x  m. 

Each  row  is  a  string  of  size  m 

output : 

Y:  a  vector  of  size  m,  where  each  entry  is  an 
unsigned  integer 

m-Hamming-distance (Xa,  Xb) : 
for  (i  =  1;  i  <=  m;  i++)  { 

Y[i]  =  Hamming-di stance (Xa,  Xb[i]); 

> 

unsigned  int  Hamming-distance (U1 ,  U2) : 
unsigned  int  D  =  0; 
for  (i  =  1;  i  <=  m;  i++)  { 

D  +=  (U1 [i]  ! =  U2 [i] ) ; 

> 

return  D; 


//  constraint-friendly  version 
m-Hamming-distance (Xa,  Xb) : 
unsigned  int  Za[m] ; 

unsigned  int  Zd[m] [m] ;  //  0-1  variables 

for  (pos  =  1;  pos  <=  m;  pos++)  { 

Za[pos]  =  Xa[pos]  ; 

> 

for  (row  =  1;  row  <=  m;  row++)  { 
for  (pos  =  1;  pos  <=  m;  pos++)  { 

Zd[row]  [pos]  = 

(Za[pos]  -  Xb [row] [pos]  !=  0)  ?  1  :  0; 

> 

> 

for  (row  =  1;  row  <=  m;  row++)  { 

Y[row]  =  Zd[row]  [1]  +  .  .  .  +  Zd[row]  [m]  ; 

> 


Figure  15 — Pseudocode  for  m- Hamming  distance  computation,  presented  two  ways.  The  second  presentation  permits  a  more  natural 
translation  to  constraints  (see  Figure  16). 


the  following  ones,  to  form  C'ested: 

M'0  -  S{Z)  =  0, 

M[  —  R(M\)  -M'0  =  0, 

M'2  -  R(M2)  •  M[  =  0, 

M'_!  -R{Mk_i)-M'k_2  =  0, 
R{Mk)-M'k_i=  0. 

The  proof  that  C'ested  and  Cnested  are  equivalent  is  similar 
to  the  proof  of  Claim  D.l  and  is  omitted  for  the  sake 
of  brevity.  Observe  that  this  construction  introduces,  per 
constraint  in  C,  k  new  variables  and  k  new  constraints, 
leading  to  the  costs  stated  above. 

E  Evaluation  benchmarks 

This  appendix  describes  some  of  the  benchmark  compu¬ 
tations  from  Section  6  and  reports  microbenchmarks  to 
quantify  our  cost  model  (Figure  2). 

E.l  Benchmark  computations 

Below,  we  cover  in  detail  m- Hamming  distance  and  bi¬ 
section  method;  the  other  benchmark  computations  in 
Section  6  (Figure  5)  are  described  elsewhere  [45]. 

m-Hamming  distance 

Recall  that  the  Hamming  distance  between  two  strings  of 
the  same  length  is  the  number  of  positions  at  which  they 
differ.  We  define  the  m-Hamming  distance  computation 
as  follows.  The  input  is  a  string,  xa,  of  length  m,  and  there 
is  also  a  predefined  set  of  m  strings,  x/, ;  the  computation 
is  to  find  the  Hamming  distance  between  the  input  string 
and  every  string  in  the  predefined  set  (i.e.,  the  output  is 


z\a)  -x\a)  =  0  (1  <  i  <  m) 

(Zfa)-Xg))-Mij-Z<f=  0  (1  <  i,j  <  m) 

(1  -zj)).(z/w-xj))=°  (1  <  i,j  <  m) 

,  =°  (!<<<*), 

Figure  16 — Constraints  for  the  m-Hamming  distance  computa¬ 
tion.  The  pseudocode  for  this  computation  is  in  Figure  15. 

a  vector  of  length  m  containing  integers).  This  formu¬ 
lation  makes  the  work  super-linear  (motivating  the  use 
of  GINGER)  and  is  similar  to  a  suggested  use  of  Apache 
Mahout,  namely  computing  “the  pairwise  similarity  be¬ 
tween  all  documents  ...  in  a  corpus”.8 

Figure  15  gives  the  pseudocode  for  the  computation,  in 
two  forms.  Notice  that  in  the  second  form,  there  are  three 
groups  of  “loops”;  each  group  corresponds  to  an  array  of 
constraints  of  a  given  type.  The  three  types  are  input  han¬ 
dling,  NOT-EQUALS-ZERO  (see  the  previous  appendix), 
and  a  summation  at  the  end.  The  constraints  themselves 
are  listed  in  Figure  16. 

We  now  describe  a  specialized  PCP  for  this  computa¬ 
tion  (such  tailoring  is  discussed  in  Section  5  and  [45]). 
Because  the  input  variables  {A}  will  be  assigned  based 
on  the  user’s  input  (§2.1),  the  only  degree-2  terms  in  the 
constraints  have  the  form  z\a)  ■  M, ,  and  z\d}  ■  z\a\  Our 
linear  PCP  captures  these  terms.  Specifically,  the  PCP  tt 
is  given  by  a  vector  w  of  the  following  form: 

(Z(fl),  M,  Z(d),  Z(fl)  <8 >M,  Z{d)  <8 )ZW). 

8https : // cwiki . apache . org/conf luence/display/MAHOUT/ 
Algorithms 
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Z\J  -  xja)  =  (0,1) 
zfj  -  x)b)  =  (0, 1) 

Z^-F((1,2).(Z^+Z^))  =  (0,1) 

constraints  for  3  sufo_computcition.  —  (Z^*  >(0,1))?  (1,1):  (0,1)” 

Z,W  .  -  Mj  •  Zj}  —  (1  —  M;)  •  (1,2)  •  (Zj}  +  zg>)  =  (0, 1) 

Z,%-  -  ( 1  -  Mi)  ■  Zj}  -  Mi  •  (1, 2)  •  (Zj}  +  Zj} )  =  (0, 1) 

^  -  Ml  ■  Z$  -  (1  -  Ml)  -(1,2)-  (Z<J  +  zg})  =  (0, 1) 

,  y}b)  ~  (i  -  ML)  •  Zg  -  Ml  •  (1, 2)  •  (Z<J  +  Zg})  =  (0, 1) 


(1  <7  <  m) 

(1  <7  <  m) 

(1  <  i  <  L) 

( 1  <i<  L) 

> 

(1  <  i  <  L,  1  <  j  <  m) 

(1  <  i  <  L,  1  <  j  <  m) 

(1  <7  <  m) 

(1  <7  <  m) 


Figure  17 — Constraints  for  the  bisection  method  computation,  as  output  by  our  compiler;  the  SFDL  source  code  is  in  Figure  18. 
The  constraints  C,,is>  are  not  unpacked  above;  they  use  inequality  comparisons  (see  Appendix  C). 


If  the  PCP  is  correct,  the  setting  of  Z^.M,  Z^  in  w 
satisfies  the  constraints.  (Here,  Z('J>  refers  to  all  zj"\  M 
refers  to  all  Ml  f,  and  7Jd>  refers  to  all  z\j  \  for  1  <  i,j  < 
m.)  The  size  of  this  encoding  is  n  =  2 +  2 m2  +  m 
elements. 

In  formulating  the  PCP  tests,  let  7r(1\  . . . ,  tt5-1  denote 
the  linear  functions  that  correspond  to  the  5  components 
of  w  above.  The  first  PCP  tests  are  two  quadratic  correc¬ 
tion  tests  (since  there  are  two  outer  products): 

TT(1)(<7i)  •  7T(2)(<72)  =  tt(4)(<7i  <S><72  +qs)  -  tt(4)(^3) 
n^\q4)  ■  i T{i\qs)  =  n(5){q4  <8>  qs  +  qs)  -  7T(5)(^6), 
where  quq4  eR  F'"  q2,qs  £r  F"r  qi,q6  F"'3. 

The  final  PCP  test  is  a  circuit  test.  Recall  that  to  test  a  sat¬ 
isfying  assignment,  V  constructs  a  polynomial,  (7  (  ■ ) ,  as 
a  random  linear  combination  of  its  constraints  (see  [45, 
§2]).  This  Q(-)  can  be  written  in  the  following  form; 

Q  (ZW,  M,  ZW)  = 

7o  +  (7i-  z(fl))  +  (72,  M)  +  (73,  ZW)+ 

(74,  ZW  ®M)  +  (75,  ZW®ZW). 

(For  similar  constructions,  see  [45,  §2  and  AppendixD].) 
The  circuit  test,  then,  is  to  construct  self-correcting 
queries  from  the  7 ;  (for  instance,  qs  and  7 i+qs),  to  supply 
the  self-correcting  7 ,■  to  7 r^,  and  to  check  that  the  sum  of 
the  results  equals  —70. 

In  our  experiments,  the  input  “characters”  (in  the 
“strings”)  are  32-bit  unsigned  quantities  (see  Figure  5), 
and  we  take  m  =  100.  Thus,  the  number  of  constraints 
is  2 m2  +  2m  =  20,200.  Also,  the  number  of  variables  is 
s  =  2 m2  +  m  (per  Figure  5),  which  is  20,100  (as  stated  in 
Figure  9).  Note  that  n,  the  size  of  the  encoding,  is  0(m3); 
with  the  standard  (non-tailored)  encoding,  n  would  be 
0(s2)  =  0(m4). 


type  Y  =  struct  {f loat [m]  Ya,  f loat [m]  Yb}; 
function  Y  output  (f loat [m]  Xa,  float [m]  Xb)  { 
var  int  i ;  var  int  j ; 
var  float [m]  Za;  var  float [m]  Zb; 

Za  =  Xa;  Zb  =  Xb; 
for  (i  =  0  to  L-l)  { 

if  (fAtMidpt(Za,  Zb)  >  0)  { 
for  (j  =  0  to  m-1)  { 

Za[j]  =  l/2*(Za[j]  +  Zb[j]); 

> 

}  else  { 

for  (j  =  0  to  m-1)  { 

Za[j]  =  l/2*(Za[j]  +  Zb[j]); 

> 

} 

} 

output. Ya  =  Za;  output. Yb  =  Zb; 

> 

Figure  18 — Partial  SFDL  code  for  the  bisection  method  ap¬ 
plied  to  a  degree-2  polynomial,  F,  in  m  variables.  The  function 
f  AtMidpt(a,  b )  evaluates  the  polynomial  F  at  the  midpoint  of 
a  and  b. 

Root  finding  by  bisection 

This  computation  identifies  roots  of  a  function.  Root¬ 
finding  of  course  has  many  uses  (in  optimization,  signal 
processing,  etc.).  The  “bisection  method”,  as  we  call  it, 
finds  a  root  of  a  continuous  function  in  a  given  interval, 
provided  the  interval  brackets  a  root.  The  method  repeat¬ 
edly  bisects  the  search  interval,  searching  in  one  of  the 
two  subintervals.  As  the  number  of  bisections  L  — >  00, 
the  search  interval  is  guaranteed  to  converge  to  a  root  of 
the  function  inside  the  given  interval. 

Our  benchmark  computation  applies  this  algorithm  to 
find  roots  of  a  degree-2  polynomial  in  m  variables,  and 
we  assume  that  the  verifier  knows  the  endpoints  of  the 
search  space.  Note  that  this  is  a  minor  restriction  since 
the  computation  can  be  modified  slightly,  with  little  ad- 
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ditional  cost,  to  have  the  prover  supply  those  endpoints 
(say  by  randomly  evaluating  the  polynomial  to  identify 
valid  endpoints).  Figure  17  depicts  the  constraints  pro¬ 
duced  by  our  compiler;  the  SFDL  source  code  is  depicted 
in  Figure  18.  The  float  and  int  types  in  our  SFDL  are 
an  extension  to  Fairplay’s  SFDL  [39]. 

In  our  experiments,  we  take  the  number  of  iterations, 
L,  to  be  8.  The  inputs  are  vectors  of  m  =  25  floating¬ 
point  numbers  (using  our  primitive  representation)  with 
Na  =  32  and  Nf,  =  5  (see  Section  4.1).  Thus,  we  can 
bound  the  computation  to  the  subset  U  =  {a/b  :  \a\  < 
2 mo,b  G  {1,2, 22, . . . ,  230}}.  This  allows  us  to  imple¬ 
ment  C/? iS>  with  145  constraints  and  140  variables  (in¬ 
cluding  the  {Mi}).  Adding  up  the  constraints  and  vari¬ 
ables  in  Figure  17,  we  get  1618  constraints  and  1528 
variables  (as  stated  in  Figure  9). 

E.2  Microbenchmarks 

To  quantify  the  parameters  in  the  cost  model,  we  run  a 
program  that  executes  each  operation  (encryption,  de¬ 
cryption,  etc.)  at  least  5000  times  using  1024-bit  keys 
with  inputs  chosen  from  different  finite  fields.  Here  are 
the  mean  execution  times  of  the  operations  (standard  de¬ 
viations  are  within  5%  of  the  means): 


field  size 

e 

d 

h 

/ 

c 

128  bits 

72  /rs 

170  /xs 

190  fj,  s 

18  ns 

69  ns 

192  bits 

85  /.is 

170  /rs 

280  ps 

45  ns 

69  ns 

320  bits 

280  /:ts 

170  fis 

560  ps 

180  ns 

69  ns 
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